Re: [Geopriv] SIP Location Conveyance -03 submitted

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Thu Jun 29 2006 - 17:33:42 EDT

At 11:13 PM 6/29/2006 +0200, Hannes Tschofenig wrote:
>I saw this mail too late and hence I posted my comments to the Geopriv and
>the SIP mailing list....

I moved that message back to the SIP list (by removing Geopriv), since the
ID belongs to SIP.

>James M. Polk wrote:
>>Geopriv WG
>>Here is the forwarded message I sent to the SIP WG list indicating a new
>>version of the SIP Location Conveyance ID is now available for review and
>>comments (on the SIP list please!).
>>This is the document that specifies SIP as a Geopriv "Using Protocol" per
>>RFC 3693 (Geopriv Requirements).
>>
>>>Date: Thu, 29 Jun 2006 14:50:44 -0500
>>>To: sip@ietf.org
>>>From: "James M. Polk" <jmpolk@cisco.com>
>>>Subject: SIP Location Conveyance -03 submitted
>>>
>>>I've submitted -03 of the SIP Location Conveyance ID for review and
>>>comments.
>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-03.txt
>>>
>>>
>>> This is a list of the changes that have been made from the SIP WG
>>> version -02 to this version -03:
>>>
>>> - general clean-up of some of the sections
>>>
>>> - removed the message examples from the UPDATE, MESSAGE and REGISTER
>>> sections, as these seemed to be making the doc less readable, and
>>> not more readable
>>>
>>> - removed the "unknown" option tag, as it was not needed with a
>>> certain combination of the Supported and Location headers
>>>
>>> - clarified the location option tag usage in Supported, Require,
>>> Unsupported, and that it shouldn't be used in Proxy-Require, and
>>> why not.
>>>
>>> - Added a basic message flow to the basic operation section (Section
>>> 4) to aid in understanding of this SIP extension.
>>>
>>> - Added a message routing flow, which is based on the location of
>>> the requestor to show how a SIP server can make a routing decision
>>> to a destination based on where the UAC is.
>>>
>>> - Articulated how a UAS concludes a UAC understands this extension,
>>> yet does not know its location to provide to the UAS. This is
>>> helpful in those times where an intermediary will act differently
>>> based on whether or not a UAC understands this extension, and
>>> whether or not the UAC includes its location in the request.
>>>
>>> - Corrected the erroneous text regarding an Unsupported header being
>>> in a 424 response. It belongs in a 420 response. (Section 5.1)
>>>
>>> - Corrected the BNF (I hope)
>>>
>>> - Corrected some text in Section 5 that read like this document was
>>> an update to RFC 3261.
>>
>>_______________________________________________
>>Geopriv mailing list
>>Geopriv@ietf.org
>>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 29 Jun 2006 16:33:42 -0500

This archive was generated by hypermail 2.1.8 : Thu Jun 29 2006 - 17:42:24 EDT