Hi all
After reading through the document I have to state that my previous comments
did not made it into the document. Hence, I "replay" them again:
http://www1.ietf.org/mail-archive/web/geopriv/current/msg02555.html
A few additional things:
Change from:
"
This document describes how Location can be "conveyed" (that is,
sent on the Internet) from a SIP user agent, or in some
circumstances a proxy server acting on behalf of a user agent, to
another entity using the SIP [RFC3261] protocol. Here "Location" is
a description of the physical geographical area where a User Agent
currently exists. This document uses the term "conveyance" to
describe scenarios in which a SIP user agent client (UAC) is telling
or informing a user agent server (UAS) where the UAC is. This is
different from a UAC asking or seeking the location of where the UAS
is. Conveyance is a push model, where seeking is a pull model, and
therefore not discussed here.
"
to:
"
This document describes how geodetic and/or civic location
information can be conveyed from a SIP user agent, or in some
circumstances a proxy server acting on behalf of a user agent, to
another entity using the SIP [RFC3261] protocol.
This document does not describe mechanisms for subscription and
notification.
"
Regarding the last sentence I wonder why you this document indicates
that Geolocation header may appear in a SUBSCRIBE / NOTIFY message.
Regarding:
"
This document uses the term "conveyance" to
describe scenarios in which a SIP user agent client (UAC) is telling
or informing a user agent server (UAS) where the UAC is.
"
I am not sure that this document is associating semantic to the
location information with respect to the UAC. It just carries the
location information from A to B. I believe that the information
carried inside the PIDF (entity attribute) would tell to which entity
this location information refers to.
Regarding:
"Conveyance is a push model, where seeking is a pull model, and
therefore not discussed here.
"
I would omit this push vs. pull discussion since the draft also talks
about LbyR and then these things get fuzzy.
Please use the following terms as capitalized words since they refer
to terms introduced in the GEOPRIV requirement RFC. We did this in
other docs as well: target => Target, using protocol => Using
Protocol, location server => Location Server, location object =>
Location Object, location recipient => Location Recipient
Regarding:
"
A
PIDF-LO is an XML Schema specifically for carrying geographic
location of a thing.
"
A PIDF-LO is an XML document extending PIDF to carry location
information.
The introduction seems to have grown over time and at several
paragraphs it now says "This document" or in "In this document"
Maybe someone would like to ensure that it reads nicely rather than
patched together.
Emergency case:
I believe that all occurrences of emergency services should be deleted
from the document since this document is generic in its nature. Let
the Phone BCP deal with the emergency issue since it has todo so
anyway
Put a comma before "which".
Put a comma after "i.e." and "e.g."
"message-routed-on-this-uri":
This functionality was introduced quite late in the process.
If I recall it correctly then it would be used for debugging purposes.
Is this correct? (nothing more - right?)
"retransmission-allowed":
With the "retransmission-allowed" element, the rule maker can control
distribution of the location information for location-based routing.
It is clear how these rules are set with location information being
added by an end point. In that particular case it is implicit that the
end point want to use location information for routing. If it would not
want to use location information for routing it would have to encrypt it
anyway.
Hence, is this functionality really necessary?
This document talks about a LIS but does not define what it is :-)
Delete this statement:
"
This will likely
not suit some services already being considered in the IETF at the
time of this writing, such as emergency calling.
"
Section 5:
"
Possession of a dereferenceable location URI may be equivalent to
possession of the location information itself and thus TLS SHOULD be
used when sending location-by-reference.
"
What does this mean?
You always have to use TLS when you do not use S/MIME regardless whether
you send it by value or by reference.
Exception: Emergency Services
Section 5.1:
"
There MAY be future work defining additional error information, say
in an XML body, indicating exactly what the error was, if any of the
new Warning codes are ambiguous.
"
Delete this sentence -- RFC 2119 language not appropriate.
Section 5.1:
"
This is a seeking or
pull model scenario, which is not defined here, and left for future
study.
"
This document defines the ability to carry location information in a
SUBSCRIBE/NOTIFY exchange.
Let's assume it wouldn't be defined in this document then it would be
available already via the rest of the presence work
The security consideration is far too short for this sensitive topic.
Ciao
Hannes
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
