Re: [sipcore] Questions on location conveyance and dereferencing

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

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. 

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. 

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.

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. 

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