Re: [sipcore] Questions on location conveyance and dereferencing

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi John, 
 

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

James Polk forgot to add it for a couple of years. We managed to clarify
this aspect recently on the mailing list. 
The next version of the draft (which will hopefully show up before the
next IETF meeting) was promised for this month. 
 

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

In your enterprise LIS for emergency services you will most likely want
to figure out who is going to consume that reference. Quite likely the
PSAP will consume the reference. If so, you better talk to the PSAP
responsible for that specific area. 

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

XMPP does not provide equivalent functionality of SIP location
conveyance. 
So, another non-issue. 

> 
> >
> > 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.
That's not uncommon for the Web today either. If you get a reference
that you cannot resolve then it fails. 
I have no problem with an extension to HELD asking for a specific type
of reference. Providing both references, a SIP and an HTTP based
reference, back to the end host is not out of question either. 

Ciao
Hannes


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