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

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

At 01:23 AM 10/28/2010, Elwell, John wrote:
>
>
> > -----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.

If others agree, I'm ok with making LRs supporting this spec have to 
support a or a group of schemes. I think this will easily get 
facetime during the preso in SIPCORE to get high BW feedback too.


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

I see the distinction, but to let you know, I'm not the one who 
really needs convincing among the editor team. Jon is fairly open 
about being opposed to have a bunch of error codes, but I personally 
think the list below is what I would do if it were up to me now. I 
think that is concise, has no ambiguity or room for error (pardon the pun).

James


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