Re: [sipcore] Location Conveyance -04 submitted, here's the changes

Thanks a lot for revising this document.

I'm pretty comfortable with the document at this point, but have just  
one minor question: Why are you still limiting the number of location  
values?  Why are three values harmful, but not two?  This still seems  
like pointless ABNF legislation.

--Richard

On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:

> SIPCORE
>
> I've submitted the next version of Location Conveyance (-04)
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-04.txt
> and I believe this version has addressed each open item from the  
> mailing list, as well as what was discussed and agreed to in the  
> Maastricht meeting.
>
> I have attempted to identify each open issue with the specific  
> resolution here (in no particular order):
>
> - Martin wanted Section 3 to be broken up into subsections, each  
> revolving around each of the 4 diagrams. I have done this.
>
> - allowed a maximum of two (up from one) locationValues to be  
> present in the Geolocation header value. The text however recommends  
> against inserting a second value. This was agreed to in Maastricht.
>
> - Because we're allowing a max of two locationValues, they can be in  
> separate Geolocation headers in the SIP request. This scenario  
> necessitates bring a previous version's paragraph in stating that a  
> 'SIP intermediary MUST inspect all instances of each Geolocation  
> header before considering the routing-allowed parameter to be  
> considered =yes', to ensure there isn't a conflict in the 'other'  
> Geolocation header that states the policy is =no.
>
> - with the ability to add a second locationValue, it is necessary to  
> warn against doing this (confusion at the LRs).
>
> - Added the "you break it you bought it" philosophy to SIP  
> intermediaries that choose to insert a second location where one  
> already existed, especially for inserting a location URI in the  
> downstream SIP request.
>
> - Fixed the ABNF to handle zero, one or two (but no more)  
> locationValues according to the agreement in Maastricht.  There is a  
> one-off use case which won't be in play very often, but is a WG item  
> in ECRIT that several wanted to allow the possibility for (involving  
> allowing one coarse and one highly accurate location in the same SIP  
> request).
>
> - Paul K. wanted the use-case in which a SIP intermediary inserts a  
> locationValue where one didn't exist previously, and received a 424  
> (Bad Location Information) to that inserted location, from having  
> the 424 propagate towards the UAC (as the UAC might not know what to  
> do with a 424). This is now covered in Section 4.3.
>
> - changed existing text to "MUST NOT" from "does not" about a 424  
> not terminating an existing dialog (just increased the strength of  
> this.
>
> - I added the 424 to the table 2 entry in which the Geolocation  
> header can be in only this response.
>
> - I added text stating the conditions for adding a Geolocation  
> header value to the 424, to make it clear what is and what isn't  
> allowed for this.
>
> - Martin wanted me to add back in the top level Geolocation-Error  
> codes 100, 200, 300 and 400, which I did in section 4.3.
>
> - rejected the idea that the geolocation option-tag hasn't been  
> justified.
>
> - Added RFCs 2616, 2818 and HELD Deref ID to the references section  
> because I added the ability to include HTTP: and HTTPS: URIs, and  
> stated if received, they should be dereferenced according to the  
> HELD Deref doc.
>
> - changed the Section 5 examples how Martin wanted them.
>
> - Stated that GEO-URIs are not appropriate for the SIP Geolocation  
> header, according to the discussion during the Maastricht Geopriv  
> meeting.
>
> - we changed the privacy section, and included a ref to the Geopriv  
> Arch doc, according to the agreement in Geopriv at Maastricht.
>
>
> Comments are encouraged
>
> We plan to request (3rd?) WGLC during the SIPCORE meeting in Beijing  
> (to give folks a sense of our plans).
>
> James/Brian/Jon
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore