Subject: [Sip] SIP Location Conveyance-08 is available

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Jul 2007 21:19:21 -0500

SIP WG

I have updated Location Conveyance to -08.

http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-08.txt

Venture below for the list of changes, already know issues with -08, 
and what I know I'm adding (unless told otherwise  ;-)

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Session Initiation Protocol Working 
>Group of the IETF.
>
>         Title           : Location Conveyance for the Session 
> Initiation Protocol
>         Author(s)       : J. Polk, B. Rosen
>         Filename        : draft-ietf-sip-location-conveyance-08.txt
>         Pages           : 38
>         Date            : 2007-7-11
>
>This document defines an extension to the Session Initiation
>    Protocol (SIP) to convey geographic location information from one
>    SIP entity to another SIP entity.  The extension covers end to end
>    conveyance as well as location-based routing, where proxy servers
>    make routing decisions based on the location of the SIP user agents.

The following is a brief listing of the (numerous) changes made:

- made clear the original intention of the doc to show that this is 
for sending location of a Target, and not limited to sending location 
of the UAC, as I've read in several messages to the various lists 
about this ID's purpose.  Each PIDF-LO has an identifier in it.  This 
means more than one PIDF-LO can be in the same SIP request *but* each 
can be for their own Target. This means more than one Target location 
can be in the same request.  That said, only one Target can be in one 
PIDF-LO. Meaning, all location information contained within a single 
PIDF-LO must point at the location of the identified Target of that 
PIDF-LO, regardless of the internal formats used within the 
PIDF-LO.  This allows, for example, the mixing of civic and 
geo/coordinate location XML elements - because they all apply to the 
ONE location of the Target.

- I cleaned up the text to make Target, Location Recipient, Location 
Server, Location Object consistent.

- I changed references from "routing" a message to "retargeting" a 
message whenever the location in a request was used to determine 
where to forward the message (by a SIP server).

- Changed error reporting in a response from a Warning code to a new 
Geolocation-Error header in a  (meaning any) response.  Kept the 424 
(Bad Location Information) error for times in which a request's 
included location was the reason the request was rejected.

- Added text stating that a transaction can be either successful or 
have another response (other than 424) and still have a 
Geolocation-Error header.

- added a Geolocation header parameter "recipient=" to indication 
which SIP entity type a particular locationValue is intended for.

         OPEN ISSUE here: what does a Location Recipient
                 do if more than one locationValue point to it? (i.e.,
                 the case in which the UAS receives 2 locations
                 and both state "recipient=endpoint")

- elaborated on the existing header parameters within the Geolocation 
header "inserted-by=", "used-for-routing" (and the new "recipient=" 
parameter). The text makes it clearer than any or all 3 of these of 
these parameters can be present in a locationValue.

- expanded the list of Methods that can optionally have the 
Geolocation header to every one *but* ACK and CANCEL. I left off 
PRACK from the list, but that was by mistake - and will be corrected in -09.

- Geolocation-Error can appear in the same Methods as the Geolocation header.

- there can be one or more locationErrorValues in a response, 
allowing each location in a request to be identified as have bad 
parts, and giving the Location Recipient the ability to telling each 
location inserter what was wrong with their inserted location.

- because each locationErrorValue in a response has exactly one 
"inserter=" entity identified, this creates the ability for each 
response receiver to know of a particular locationErrorValue was 
meant for them, and to ignore all others.  This solves the spoken 
requirement of if an error is received, how does the receiver know 
that response was meant for them (since more than one entity can 
insert location into the request along the path).

- The ID RECOMMENDS now that a second locationValue not be added to a 
request that already has one for a given Target. This will lead to 
confusion by the Location Recipient.  There has been no consensus 
what to do if this situation would occur - though many have voiced 
opinions this should be addressed.  The only way I know how to 
address this is either to prioritize the locationValues based on 
which entity inserted them (trusting one over the other).  For 
example, trusting a UA inserter over a Proxy inserter.  This cuts 
into the concept of Geopriv Sighting (RFC3693).  What about trusting 
LbyR over LbyV. Unfortunately this doesn't give any notion of which 
entity inserted either location type...

- clarified that the "used-for-routing" header parameter of a 
locationValue is to be kept in the locationValue even if a subsequent 
proxy routes the request again, but on a different locationValue 
within the request.  This will help a Location Recipient determine 
how the request got to this destination (used more for after the fact 
troubleshooting).

         OPEN ISSUE here: I added text here stating something unusual in SIP,
                      the concept of inserting header values in a 
certain order to
                      ensure a path of hops could be 
determined.  Robert Sparks has
                      already pointed out there is another, more consistent way
                      to solve this. I will take his direction to be 
more consistent here...

- Clarified the rough consensus stance that location not be carried 
in any response.  This is for fragmentations reasons, as well as the 
inability to error that locationValue.

- increased the number of IANA registrations to include the 
locationValue header parameters, and given brief definitions to the 
Geolocation-Error codes (similar to what Warning has); also 
registered the new Geolocation-Error header.

- Appendix B was all the "changes since last version". It is now an 
INVITE request with an S/MIME protected PIDF-LO using the civic 
format.  This location position is the same as the (x/y) Coordinate 
position in section 4.1.

- plus cleaned up a bunch of other little nits throughout doc

What I already know is missing or in error in -08 (that will be fixed in -09)

- there is no event package for the fetch function the SUB/NOT to 
dereference an initial PIDF-LO of the Target.  This event package 
will be (something like) location-fetch, for one-time only fetches of 
location of the Target, not for pending subscriptions or location 
tracking or anything like that.  Someone wanting that capability will 
need to wrote a new doc for that, cuz it's not going in this doc.

- I missed changing the Geolocation-Error examples from the format of 
the Warning header, that used SPACE between header values, where the 
BNF of the Geolocation-Error called for a SEMI between values. This 
is an artifact from changing this error reporting from Reason to 
Warning to a new header.... I got the 1st example right, then missed 
the remaining ones (oops!)

- Need to fix the BNF of the Geolocation-Error header wrt to the host 
name - to be equivalent to the "sent-by" FQDN of the Via, identifying 
the location inserting entity of a particular locationValue (that had 
an error in it).

- I need to get a solution idea for and then consensus of the two 
OPEN ISSUES listed above...

What I'm planning on adding (until rough consensus tells me not to) 
is the following:

- the ability for the Geolocation-Error locationErrorValue to contain 
each CAType that the Location Recipient had a problem with (from the 
request).  The CAType values will *NOT* be sent, just the CATypes 
themselves.  This greatly adds to the information about the location 
error experienced by the Location Recipient (to the Location 
inserter) in the response.

- I might break out the text regarding the number of locations in a 
request, and what those limitations are; because I've had a lot of 
discussion about how this facet is interpreted - and more than a few 
don't get it right - meaning I'm not being clear enough.  This means 
there is a lack of clarity in the text.  A separate subsection might 
be necessary.

comments (or questions) are appreciated

James

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Jul 2007 11:06:09 -0700

Hi James,
	
>
>- added a Geolocation header parameter "recipient=" to indication which SIP entity type a particular locationValue is intended for.
>

First a couple of nits, then a question on the open issue.

Section 3.2 says:
      the "recipient=" to allow recipients to infer what SIP element
      type this locationValue was intended to be for.  The types are
      "endpoint", meaning the ultimate destination UAS;
      "routing-entity", meaning SIP servers; and "both" meaning this
      locationValue is to be viewed by both types of SIP entities. 

The example in 4.2, though, has "recipient=server".  That should
get shifted to "routing-entity", if I understand things correctly.

The document also points to 3261 for Absolute URI, which appears to
derive that from RFC 2396, Section 5.  Would it be a problem to update
that to RFC 3986, Section 4.3, since 3986 is now a full standard?

So, the open issue you raise is what a routing-entity or endpoint
does when it receives multiple locationValues for which it is the
recipient.  For the endpoint, I believe that the answer is
application specific.  For some uses, the most recently added may
get used; for others, the first added; for others, all of them
may get evaluated and some other application-specific judgement call
made (an application might prefer the most precise, a specific
address type, or something else).  I think, though, that this
document can stay silent about the endpoint's selection beyond the error
code text describing 424.

For the routing-entity, though, I think that silence is probably
not workable.  I would personally say that a routing-entity receiving
multiple locationValues should always use the most recently
added unless that location would generate a 424; in that case, it
can examine the previously asserted locations in reverse order of
addition until it finds one that is valid or generates the 424.

Would that make sense to you?
				regards,
					Ted