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

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]] 
> Sent: 27 October 2010 20:59
> To: Elwell, John; James M. Polk; [e-mail]
> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
> At 02:37 PM 10/27/2010, Elwell, John wrote:
> >
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[e-mail]]
> > > Sent: 27 October 2010 20:05
> > > To: Elwell, John; James M. Polk; [e-mail]
> > > Subject: RE: [sipcore] Location Conveyance -04 submitted,
> > > here's the changes
> > >
> > > At 08:17 AM 10/27/2010, Elwell, John wrote:
> > > >I am happy to see that http and https are added as schemes in
> > > >locationURI. However, looking at 4.6, I am still 
> uncomfortable that
> > > >SIP-, SIPS- and PRES-URI are recommended and but HTTP- 
> and HTTPS-URI
> > > >are not recommended (by virtue of the fact they are only MAY
> > > >strength, for use when one disregards the SHOULD for SIP-,
> > > SIPS- and PRES-).
> > >
> > > well... this is a SIP document, why shouldn't a SIP-based URI be
> > > recommended? Do you want me to say HTTP:/HTTPS: is allowed in
> > > some other way?
> > >
> > >
> > > >We had an earlier thread starting here:
> > > 
> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03149.html
> > > >in which questions were asked about what one must 
> support. The text
> > > >in 4.6 says nothing about what a LR must support. The 
> implication is
> > > >that it either has two support all of the 5 schemes listed for
> > > >sending in a request, or it can choose which to support 
> and reject
> > > >any that it doesn't support.
> > >
> > > right now it is the latter, but I would - if I must - 
> propose making
> > > SIP:/SIPS:/PRES: mandatory if there is any URI scheme 
> that is (again,
> > > this is a SIP doc).
> >[JRE] But the event package is [ID-GEO-FILTERS] and is based upon 
> >RFC 3856, a SIMPLE document. Not all SIP implementations 
> support SIMPLE.
> 
> [jmp] Yes, but realistically - fewer will support HELD-Deref...
> 
> >On the other hand, I can see benefits in this (ability to receive 
> >notifications when location changes, plus filters).
> 
> [jmp] I believe Brian wrote the Filters doc with that in mind (i.e., 
> the benefits).
> 
> >If the consensus is SIP/SIPS/PRES is the only mandatory one, I can 
> >live with it.
> >
> >On re-reading 4.6, I see that, although the text "These schemes MUST 
> >be implemented according to this document" is within the paragraph 
> >concerning what you SHOULD place in a SIP request, perhaps it is 
> >intended to include what MUST be supported on receipt too, so 
> >perhaps it is OK as is, or perhaps it should say "A location 
> >recipient MUST implement these schemes".
> 
> [jmp] If we end up choosing a mandatory to implement scheme (or 
> scheme set), then I think we can state that receivers MUST implement 
> that scheme (set).
> 
> [jmp] Do you (or others) believe this should be done regardless of 
> any mandatory to implement sending scheme, or wait until there is a 
> mandatory to implement sending scheme?
[JRE] What we want to achieve is that there is a certain group of schemes (one or more) that, if sent by the sender, will be supported by any receiver that supports location-conveyance. Assuming the WG settles on SIP/SIPS/PRES as that group of schemes, I think the present words get quite close to what we require. However, as I mention above, the paragraph talks about schemes to send in the request, so there is some ambiguity as to whether the "MUST be supported" includes receipt or not. Hence my proposed word change above.

> 
> 
> > >
> > >
> > > >In practice, as pointed out on the thread, the schemes 
> effectively
> > > >boil down to 2 mechanisms: SIP and HTTP (if we for now ignore the
> > > >absoluteURI option, which effectively leaves it open ended). So
> > > >perhaps it is not unreasonable to mandate support for 
> all 5 schemes
> > > >(both mechanisms) by a recipient, although it does raise the bar
> > > >somewhat for recipient implementations.
> > >
> > > Several of us have and currently believe that is raising the bar a
> > > little too high.
> > >
> > > >I recall there was some interest on the thread in limiting to a
> > > >single MUST support, and some interest in that scheme 
> being HTTP(S).
> > > >I am not sure we reached consensus on this. I don't have a strong
> > > >opinion, but we certainly need some text to clarify 
> things one way
> > > >or the other.
> > > >
> > > >Furthermore, it is unclear which code to use in a 494 
> response when
> > > >rejecting an unsupported scheme - presumably the top 
> level 400, but
> > > >that says nothing about why dereference failed. Even if all the
> > > >named schemes were MUST support (so you would never 
> reject these),
> > > >there could be other schemes under absoluteURI that you
> > > would want to reject.
> > >
> > > The conclusion from the San Diego adhoc bof on this ID 
> was to limit
> > > the number of error types to specific different 
> actionable ones. At
> > > that adhoc, I had roughly 22 different error types, one 
> set included
> > > the ability to indicate which URI scheme wasn't supported 
> and which
> > > ones were. That idea was roundly rejected (most strongly by our
> > > newest co-author Jon Peterson).  I believe it was Henning 
> (and maybe
> > > Hannes) that wanted the error codes limited as well, and to allow
> > > this RFC-to-be to be extended with an XML body in the 
> response that
> > > included a much more detailed error explanation and ways 
> detailed in
> > > how to resolve the problem.
> > >
> > > No one has written that ID yet, so I don't know where that
> > > thought is now.
> > >
> > > That said, -04 doesn't have a 494 response articulated because
> > > location specific rejections are for the 424 (Bad Location
> > > Information) response. Jon and I talked just last week 
> about what do
> > > we do when an LR supports one URI scheme and receives another URI
> > > scheme (i.e., supports SIP:/SIPS:/PRES: URIs but gets an 
> HTTP:/HTTPS:
> > > URI). We couldn't come up with anything that didn't have a lot of
> > > holes in it, so we left it for now.
> >[JRE] Sorry, 494 was a typo, I meant 424. What sort of holes would 
> >you have if you specified 401, say, as "URI scheme not 
> >supported"?  I guess one difficulty is what does the UAC do about 
> >it, if it doesn't have the means for obtaining a reference with a 
> >different URI. Was that the sort of hole you had in mind?
> 
> [jmp] Jon and I talked specifically about adding a 401 "URI scheme 
> not supported", but his point was "what does that really tell you?" 
> and I tried to plead that it would mean that this scheme (set) (i.e., 
> SIP based or HTTP based) wasn't supported, and to send the other 
> scheme (set). His counter was that what happens when there is more 
> than one scheme set to choose from, then what does a 401 really mean 
> that a 400 doesn't already? I didn't really have a good answer for 
> that one. In other words, if we're only ever going to have a choice 
> between SIP and HTTP, then the 401 would work. Once you have a 3rd 
> (or more) choice, it all falls apart.
[JRE] I would say that there would be a distinction between 401 (I don't know how to deal with that scheme because I don't support it) and 400 (which would include things like error response to the SIP/HTTP request, or dereference yielded a location that I couldn't interpret (unless that is a 100), etc.).

John


> 
> The best way around this is to indicate which choice of scheme you 
> want in the 424, perhaps this could become (Jon - don't 
> hyperventilate!)
> 
> 401 "URI scheme not supported - send SIP:URI"
> 402 "URI scheme not supported - send SIPS:URI"
> 403 "URI scheme not supported - send PRES:URI"
> 404 "URI scheme not supported - send HTTP:URI"
> 405 "URI scheme not supported - send HTTPS:URI"
> 
> and just add to the list when someone wants a new URI scheme 
> supported.
> 
> James
> 
> 
> >John
> >
> >
> > >
> > > James
> > >
> > >
> > > >John
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of James M. Polk
> > > > > Sent: 27 October 2010 05:32
> > > > > To: [e-mail]
> > > > > Subject: [sipcore] Location Conveyance -04 submitted, here's
> > > > > the changes
> > > > >
> > > > > SIPCORE
> > > > >
> > > > > I've submitted the next version of Location Conveyance (-04)
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> > > > > n-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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > >
> > >
> > >
> 
>