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

["James M. Polk" <[e-mail]>]

At 06:00 AM 7/20/2010, Elwell, John wrote:
>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?

good catch! At this time (in -03) there is only one Geolocation 
header, so there is no need to look further for a "no".


>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.

this is the same catch as above - and there is only one locationValue 
currently.

>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?

The Geopriv "Using Protocol" is from the original requirements doc 
from SIPPING, which is now the appendix here. It comes from RFC 3693, 
which Geopriv is going to revise eventually with their Geopriv Arch 
ID, that removes the use of this term.  Geopriv Arch is only an 
update to 3693, and not a replacement, meaning 3693 will remain 
actively appropriate, so I'm kinda caught with which to align with.

James


>John
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of James M. Polk
> > Sent: 13 July 2010 00:55
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore