Re: [sipcore] location-conveyance-03 just submitted

James,

These are questions for clarification at this stage, rather than comments.

The ABNF for the Geolocation header field allows multiple locationValues and multiple routing-params, in any order. The text below seems to limit it to 0 or 1 locationValue and 0 or 1 routing-param, and furthermore it limits it so that the routing-param must be last. It seems this could be expressed much more precisely, and still quite easily, in the ABNF. Of have I misunderstood something?

Although the text "The Geolocation header field has zero or one locationValue, but 
   MUST NOT contain more than one locationValue."
limits the header field to having a maximum of one locationValue, text further down "another 
   instance of the Geolocation header"
suggests that there can be multiple instances of the header field and hence multiple locationValues. So a request can contain multiple locationValues, but not in the same header field instance. Is this really what is intended?

Unrelated to the above, concerning the text:
"Other URI schemas used in the location URI MUST be reviewed against 
   the RFC 3693 [RFC3693] criteria for a Using Protocol"
Who must review? The protocol implementer? How is this testable?

John

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk
> Sent: 13 July 2010 00:55
> To: sipcore@ietf.org
> Subject: [sipcore] location-conveyance-03 just submitted
> 
> SIPCORE
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> n-conveyance-03.txt
> 
> This version is a fairly radical departure from previous versions of 
> the (long standing) effort.  This time the doc didn't grow...
> 
> We added Jon Peterson as a co-author, and he helped in Anaheim 
> propose a significantly less complex way of specifying location 
> conveyance for SIP. More than 95% of the doc has been rewritten by 
> Jon and I, with a net result of 27 less pages of text (52 to 25 now).
> 
> We took out the terms and concepts of following parameters:
> 
> - inserter
> - inserted-by
> - used-for-routing
> - host-id
> - node-id
> 
> as well as limiting the number of locationValues to *ONE*, in 
> a SIP request.
> 
> We removed the ability for SIP intermediaries to add location along 
> the way unbeknownst to the UAC (with one infrequently used 
> exception). In this way, location errors are only end-to-end, so 
> there is no need to identify which entity added location to make sure 
> the right entity reacted the right way when an error was caused by 
> the location they inserted, and not that of another entity's inserted 
> location (which is all very confusing).
> 
> We added the ability for a SIP intermediary to augment a location 
> with what the UAC should send in a subsequent request, and the 
> ability to verify this augmentation is present before successfully 
> processing that request. This is in line with both RFCs 4479 and 5491.
> 
> Comments are appreciated
> 
> James
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 