[sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3

["Elwell, John" <[e-mail]>]

I focused on sections 1 to 3, since they have been subject to
substantial changes. I think the changes on the whole are an
improvement, but I still have some minor comments and nits.

Minor comments:
- "Location Information Server (LIS) - a logical server that stores 
      geolocation records of Targets, which correspond to LbyR URIs."
Several problems with this definition:
a) What are "geolocation records"? Elsewhere in the document we talk
about just "location" or "location information" - I doubt the need to
introduce yet another term "geolocation record", which does not seem to
be used elsewhere.
b) What exactly "correspond" to LbyR URIs. Targets certainly do not
"correspond" to LbyR URIs. Also I don't think geolocation records
"correspond" to LbyR URIs. Is it trying to say something like "these
records being identified by LbyR URIs"?
c) I don't think this definition of the term LIS is in line with usage
within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS
provides either a location by value or a reference. A URI provided as a
reference will result in a recipient contacting a server to provide the
location value, but that server is not necessarily a LIS, I believe. At
least I don't believe it acts as a LIS in this circumstance, even if the
same physical server can also be a LIS. I think where we use the term
LIS in location-conveyance, we should perhaps consider using something
like "dereferencing server" instead.

- "This document describes how Location can be "conveyed" from one SIP 
   entity unsolicited to another entity using SIP [RFC3261]."
I think it would be worth mentioning that it applies only to SIP
requests:
   "This document describes how Location can be "conveyed" in a SIP [RFC
3261] request from one SIP entity unsolicited to another SIP entity."

- Later in the same paragraph: "The phrase "location conveyance" 
   describes scenarios in which a SIP user agent client (UAC) is 
   informing a user agent server (UAS) or intermediate SIP server 
   without being previously asked where the UAC is."
This is more restrictive than the sentence in the preceding comment (in
that conveyance is constrained to start at the UAC, rather than at a
proxy). The sentence does not seem to add any value and can be dropped.

- "Location Conveyance is different from a UAC, Alice, seeking the 
   location the UAS, Bob.  Location conveyance, using SIP, never asks 
   for another entity's location be in a response.  Asking for someone 
   else's location is not discussed in this document."
This is redundant, since the sentence two comments back already says
"unsolicited". If we really need to say anything, we can much more
simply say:
   "Requesting an entity to convey its location via SIP is outside the
scope of this document."

- "This document describes the
   extension to SIP for how it complies with the Using Protocol 
   requirements, "
I think this would be better worded as:
  "This document specifies an extension to SIP to allow it to be a Using
Protocol in compliance with the requirements of [RFC 3693]."

- "Common terms are in Section 1. Section 3 provides an overview of SIP
   location conveyance.  Section 4 details the modifications necessary 
   to accomplish location conveyance.  Section 5 gives decode examples 
   of geolocation within SIP requests, both LbyV and LbyR.  Section 6 
   articulates the SIP element type behaviors for location conveyance. 
   Section 7 discusses Geopriv privacy considerations.  Section 8 
   discusses security considerations.  Section 9 IANA registers the 
   modifications made to SIP by this document from section 4."
This duplicates the table of contents (well, it hardly adds anything) -
delete.

- "Section 4 gets into guidance and limitations of this behavior."
Section 4 seems to specify normative behaviour, so I would hardly call
it guidance. I would delete this sentence. If we really need to retain
such a sentence, we should use more precise wording than "gets into".

- "It is possible, and it fact, planned in certain 
   circumstances to have SIP requests routed based on the location of 
   the target. This means SIP servers can be location recipients. If 
   this is not desired by a location inserter - the act of including 
   location into this request, then a separate indication is given in 
   the Geolocation header it this usage is allowed."
I am not sure what the last sentence means - a "location inserter" is
not an "act of including location into this request". I think what might
be undesirable is not the fact that SIP servers can be location
recipients, but the fact that they might use location information for
routing. I think the last sentence should be rewritten something like
this.
  "The location inserter is able to include a separate indication in the
Geolocation header field to denote whether routing on the basis of the
target's location is permitted."

If we do this, then the last sentence seems to follow on nicely from the
first sentence, and the second sentence seems to get in the way, so
delete the second sentence. If we really need to retain the second
sentence, at least change "SIP servers" to "SIP proxies" (since a UAS is
also a SIP server).

- "There is no mechanism by which the veracity of these parameters can 
   be verified."
It is not clear what "these parameters" refers to, because the term
"parameter" has not been used in the preceding text. It would be best to
enumerate the particular fields that this refers to.

- "They are hints to downstream entities on how the 
   location information in the message was originated, intended and 
   used."
The words "was ... used" do not make sense - the information has not yet
been used - merely conveyed. I am not sure what is intended here.

- " LbyR refers to a UA 
   including a location URI in a SIP request header field which can be 
   dereferenced by a Location Recipient to receive Alice's Location 
   Object, in the form of a PIDF-LO."
The header field is not dereferenced, it is the location URI that is
dereferenced. I would suggest (also making other parts of the sentence
more generic):
   "LbyR refers to a Location Server
   including in the header of a SIP request a location URI that can be 
   dereferenced by a Location Recipient to receive a Location 
   Object, in the form of a PIDF-LO, representing the Target's
location."


Nits:

- In the abstract, "where SIP servers 
   make routing decisions based on the location of the user agent 
   clients"
Change "clients" to "client", since a SIP request can have only one UAC.

- "directly or indirectly from transmitting SIP 
   entity"
Change to
  "directly or indirectly from a transmitting SIP 
   entity"

- "In 
   other works"
Change to
  "In 
   other words"

- "a new SIP header"
Change to:
  "a new SIP header field"
(and likewise for "a new header" later. Also other places in the
document where "header" is used rather than "header field", even though
we are referring to only a part of the SIP header.)

- "that points to the where the
   location is"
Change to:
  "that points to where the
   location is"

- "either in the SIP request itself "
I think it would be more accurate to say:
  "either in the body of the SIP request"

- "or on an external server (LbyR)"
It is not clear what "external" is relative to. Change to:
  "or on a server (LbyR)"

- "Transport Layer Security is expected when a request contains 
   a target's location.  Some implementations will choose to have 
   S/MIME to encrypt message bodies from source to destination."
Shouldn't we have a paragraph break before this?


John