Review of <draft-ietf-sip-location-conveyance-07.txt>

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