Re: [sipcore] Questions on location conveyance and dereferencing

["Winterbottom, James" <[e-mail]>]

Hi John,

I thought that I had explained earlier that the prose concerning URI restrictions was going to be lifted some to include HTTP and HTTP(S), and I think that this will be reflected in the ABNF in that absoluteURI will probably be the only type included. James P and Jon P please correct me if this last bit is wrong.

When a LIS supporting HELD returns a locationURI, it actually returns a locationUriSet, which contains a set of URIs for different schemes at all point to the same resource. So I think that this addresses your second concern below.

On the MUST implement scheme, I have already provided my preference and justified it.... *8)

Cheers
James


________________________________________
From: Elwell, John [[e-mail]]
Sent: Friday, August 13, 2010 5:14 AM
To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; [e-mail]
Subject: RE: [sipcore] Questions on location conveyance and dereferencing

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[e-mail]]
> Sent: 13 August 2010 10:53
> To: ext Winterbottom, James; Elwell, John; [e-mail]
> Subject: RE: [sipcore] Questions on location conveyance and
> dereferencing
>
> John,
>
> I believe you make it more complicated than it really is.
>
> We have two mechanisms in SIP Location Conveyance, namely one based on
> SIP and the other one based on HTTP. The two clearly provide different
> capabilities.
[JRE] I am not sure what you mean here. If I search location-conveyance for "HTTP" I don't find it. I assume HTTP is covered by "absoluteURI" in 4.1, however. In fact there is a conflict - section 4.6 doesn't permit "absolute" URI - it says a location URI MUST be SIP/SIPS/PRES. Furthermore, section 8.6 establishes a registry, which allows other URI schemes beyond SIP/SIPS/PRES to be added - presumably under the umbrella of "absoluteURI", but this too is in conflict with 4.6. Anyway, my interpretation is that the ability to use HTTP is intended, but these three sub-sections are certainly in a mess and don't give much of a clue to this possibility. A more explicit mention of HTTP(S) would certainly be helpful.


>
> For emergency services I suspect that for a very, very long time the
> different parties will agree, which one they are going to
> use. The fixed
> line operators will opt for the HTTP one and maybe the cellular
> operators will go for the SIP based solution. HTTP will more
> or less be
> the baseline.
[JRE] That in itself is an interop problem. For example, if I deploy an enterprise LIS, how do I know whether it should give out HTTP or SIP URIs to its SIP UAs for inclusion in the Geolocation header field?

>
> For non-emergency services I doubt that SIP location coneyance will be
> used anytime in the near future. The reasons is quite simple: some
> players will continue to struggle with the business model.
> Additionally,
> most applications use the HTTP-based web (and not SIP). If you look at
> the deployment of the W3C geolocation API then you will
> certainly agree
> with me and none of the stuff we are discussing here is relevant.
[JRE] Yes, and even if applications use presence, they might use XMPP rather than SIMPLE.

>
> Hence, the only solution that is available is an end host based
> approach; this allows location to be conveyed inband in
> protocols, such
> as the Geolocation API. For the non-emergency service use case the
> "negotiation" is quite simple: You send something that isn't
> understood
> by the other party. You get an error back.
[JRE] So you try again with something else, and that fails too - not very satisfactory. I think a MUST implement scheme is likely to be the best solution, even if we allow other schemes to be conveyed too.

John


>
> I hope that answered your question.
>
> Ciao
> Hannes
>
> > -----Original Message-----
> > From: ext Winterbottom, James
> [mailto:[e-mail]]
> > Sent: Friday, August 13, 2010 12:35 PM
> > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo);
> > [e-mail]
> > Subject: RE: [sipcore] Questions on location conveyance and
> > dereferencing
> >
> > Hi John,
> >
> > Yes, this indeed a tricky one.
> > I must admit that I am biased here. I think that location has
> > a huge range of application beyond just emergency calling,
> > and I think that a lot of this will be implemented over HTTP,
> > HTML5's geolocation capabilities are just one example. So, if
> > we have to standardize on just one scheme being mandatory
> > then I will argue (probably for a very long time) that HTTP
> > and HELD are the best schemes to mandate.
> >
> > But again, this is only one option and one opinion. I do
> > think that supporting multiple schemes in the same header may
> > however resolve something things, if we can agree on a MUST
> > implement scheme.
> >
> > Cheers
> > James
> >
> > ________________________________________
> > From: Elwell, John [[e-mail]]
> > Sent: Friday, August 13, 2010 4:25 AM
> > To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo);
> > [e-mail]
> > Subject: RE: [sipcore] Questions on location conveyance and
> > dereferencing
> >
> > James,
> >
> > I am not really making a firm proposal, and I am indeed aware
> > of the history of location-conveyance and don't want to go
> > back to the multiple locations model that we had previously.
> > However, for a single location, if there are multiple URI
> > schemes, I see the following possibilities:
> > - limit the number of URI schemes and say the recipient MUST
> > implement all (the ultimate version of this is to have only a
> > single URI scheme);
> > - define a limited number (perhaps just one) of MUST
> > implement URI schemes, and allow the conveyance of multiple
> > URIs with different schemes, all referencing the same
> > location resource, at least one of which is a MUST implement scheme;
> > - have some sort of negotiation mechanism - but I don't want
> > to go there because of adding round-trips, particularly a
> > problem for emergency calls.
> >
> > Any other possibilities?
> >
> > John
> >
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:[e-mail]]
> > > Sent: 13 August 2010 10:14
> > > To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo);
> > > [e-mail]
> > > Subject: RE: [sipcore] Questions on location conveyance and
> > > dereferencing
> > >
> > > Hi John,
> > >
> > > I am inclined to agree that proliferation of URI schemes may
> > > be a problem. I am also inclined to think that there really
> > > aren't that many common URI schemes with multiple
> > > interpretation with regard to how you get location
> > > information from them. I could be wrong here though.
> > >
> > > As far as the HELD side of things go, I was really thinking
> > > that you would get a URI from the LIS that uniquely
> > > identifies the Target/resource, as is described in the
> > > dereference draft.
> > >
> > > Previous revisions of the conveyance draft have allowed
> > > multiple header instances and it would have been possible to
> > > include additional URI schemes by adding abother header. I
> > > don't really want to go back to this scheme. If you are
> > > proposing that a single header may include multiple URI
> > > types, this might work, but I would oppose forcing these to
> > > be directly specified in the ABNF since this would limit
> > > extensibility unnecessarily.
> > >
> > > Cheers
> > > James
> > > ________________________________________
> > > From: Elwell, John [[e-mail]]
> > > Sent: Friday, August 13, 2010 4:04 AM
> > > To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James;
> > > [e-mail]
> > > Subject: RE: [sipcore] Questions on location conveyance and
> > > dereferencing
> > >
> > > In fact, proliferation of URI schemes is a problem. If we
> > > have n URI schemes standardized for inclusion in the
> > > Geolocation header field, then a recipient would need to
> > > support dereferencing for all n schemes. There is no
> > > negotiation mechanism whereby the inserter can select a
> > > scheme that the recipient is known to support. Sounds like an
> > > interop nightmare. Perhaps we should go as far as limiting it
> > > to a single scheme: HTTPS (using HELD with
> > > identity-extensions)? This would just get you the location,
> > > without the rest of presence. Or perhaps we should allow in
> > > the Geolocation header field several URIs with different
> > > schemes, any of which can reach the same location resource.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Tschofenig, Hannes (NSN - FI/Espoo)
> > > > [mailto:[e-mail]]
> > > > Sent: 13 August 2010 09:37
> > > > To: ext Winterbottom, James; Elwell, John; [e-mail]
> > > > Subject: RE: [sipcore] Questions on location conveyance and
> > > > dereferencing
> > > >
> > > > Good questions, John!
> > > >
> > > > I don't know why we need SIP/SIPS and the PRES URI
> > scheme. Wouldn't
> > > > SIP/SIPS already be sufficient?
> > > >
> > > > If you only use RFC 3856 then you have no way to filter
> > > location; you
> > > > might end up getting a lot of notifications. Still, it works.
> > > >
> > > > If you use RFC 3856 with the location filters then you can
> > > > additionally
> > > > limit the number of notifications you get. The location
> > > filters works
> > > > reuses RFC 4661 to a certain extend but my intention was that
> > > > you do not
> > > > need to implement the full RFC 4661 for location filtering
> > > because you
> > > > do not need it  nor does it seem to be useful either. Using
> > > > RFC 4661 on
> > > > the other hand would not get you too far in the area of location
> > > > filtering.
> > > >
> > > > So, the options are:
> > > >
> > > > A) RFC 3856
> > > > B) RFC 3856 + loc-filters.
> > > >
> > > > If you send a SUBSCRIBE with loc-filters and the other
> > > party does not
> > > > understand it then the error handling in RFC 3856
> should kick in.
> > > >
> > > > Does this make sense to you?
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > PS: With the work on loc-filters I suggested to get rid
> > of RFC 4661
> > > > completely and to build loc-filters on top of something entirely
> > > > different (for example a scripting language like
> > JavaScript) but the
> > > > group did not like it.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of ext
> > > > Winterbottom, James
> > > > > Sent: Friday, August 13, 2010 11:24 AM
> > > > > To: Elwell, John; [e-mail]
> > > > > Subject: Re: [sipcore] Questions on location conveyance and
> > > > > dereferencing
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Those are valid points. For the most part I have really only
> > > > > been thinking about using HTTP URIs for HELD dereferencing in
> > > > > this header, so I haven't given a whole lot of thought to SIP
> > > > > outside of loc-filters.
> > > > >
> > > > > Do you have a recommendation?
> > > > >
> > > > > Cheers
> > > > > James
> > > > >
> > > > > ________________________________________
> > > > > From: Elwell, John [[e-mail]]
> > > > > Sent: Friday, August 13, 2010 3:19 AM
> > > > > To: Winterbottom, James; [e-mail]
> > > > > Subject: RE: Questions on location conveyance and
> dereferencing
> > > > >
> > > > > James,
> > > > >
> > > > > Thanks. True, this could be used, but the point is, if I
> > > > > receive a SIP/SIPS-URI in a SIP Geolocation header field, how
> > > > > do I know what to use (e.g., RFC 3856, RFC 3856 + RFC 4661,
> > > > > RFC 3856 + RFC 4661 + loc-filters, some other event package).
> > > > > Unless something is specified in location-conveyance, how do
> > > > > I, as location recipient, know which event package and
> > > > > extensions are likely to work at the referenced resource?
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Winterbottom, James
> > [mailto:[e-mail]]
> > > > > > Sent: 12 August 2010 09:27
> > > > > > To: Elwell, John; [e-mail]
> > > > > > Subject: RE: Questions on location conveyance and
> > dereferencing
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > I think you could use this as a basic location subscription:
> > > > > > http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-11
> > > > > >
> > > > > > There is already a lot of protest against point 2, and I
> > > > > > believe that this is going to be fixed.
> > > > > >
> > > > > > Cheers
> > > > > > James
> > > > > >
> > > > > > ________________________________________
> > > > > > From: [e-mail] [[e-mail]] On
> > > > > > Behalf Of Elwell, John [[e-mail]]
> > > > > > Sent: Thursday, August 12, 2010 3:21 AM
> > > > > > To: [e-mail]
> > > > > > Subject: [sipcore] Questions on location conveyance and
> > > > > dereferencing
> > > > > >
> > > > > > 1. Draft-ietf-sipcore-location-conveyance-03 defines PRES,
> > > > > > SIP and SIPS URI schemes for LbyR. For SIP and SIPS, there
> > > > > > seems to be an absence of specification of what
> event package
> > > > > > to use when submitting a SIP or SIPS SUBSCRIBE request for
> > > > > > dereference purposes. If it is not defined in this
> > > > > > specification, where is it defined?
> > > > > >
> > > > > > 2. Concerning PRES-URIs, we have the following text in 4.6:
> > > > > > "If a location URI is included in a SIP request, it MUST
> > > > be a SIP-,
> > > > > >    SIPS- or PRES-URI.  When PRES: is used, as defined in
> > > > > [RFC3856], if
> > > > > >    the resulting resolution resolves to a SIP: or SIPS:
> > > URI, this
> > > > > >    section applies."
> > > > > >
> > > > > > The words "this section applies" are rather strange, because
> > > > > > there is little else in this section. Maybe in a previous
> > > > > > iteration there was more information here (on how to use a
> > > > > > SIP/SIPS URI for dereference purposes). As things stand, the
> > > > > > absence of information on how to resolve a SIP- or SIPS-URI
> > > > > > applies also to PRES-URIs.
> > > > > >
> > > > > > 3. Also there is nothing to say what to do if the PRES URI
> > > > > > fails to resolve to a SIP or SIPS URI.
> > > > > >
> > > > > > 4. The "MUST be a SIP-, SIPS- or PRES-URI" text in cited
> > > > > > above seems to preclude the addition of future URI schemes,
> > > > > > which seems to be in conflict with 8.6 (registry
> > > > > > establishment for location URIs).
> > > > > >
> > > > > >
> > > > > > John
> > > > > > _______________________________________________
> > > > > > sipcore mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > > >
> > > > > _______________________________________________
> > > > > sipcore mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > >
> > > >
> > >
> >
>