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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
