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 [john.elwell@siemens-enterprise.com]
Sent: Friday, August 13, 2010 4:25 AM
To: Winterbottom, James; Tschofenig, Hannes (NSN - FI/Espoo); sipcore@ietf.org
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:James.Winterbottom@andrew.com]
> Sent: 13 August 2010 10:14
> To: Elwell, John; Tschofenig, Hannes (NSN - FI/Espoo);
> sipcore@ietf.org
> 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 [john.elwell@siemens-enterprise.com]
> Sent: Friday, August 13, 2010 4:04 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James;
> sipcore@ietf.org
> 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:hannes.tschofenig@nsn.com]
> > Sent: 13 August 2010 09:37
> > To: ext Winterbottom, James; Elwell, John; sipcore@ietf.org
> > 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: sipcore-bounces@ietf.org
> > > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext
> > Winterbottom, James
> > > Sent: Friday, August 13, 2010 11:24 AM
> > > To: Elwell, John; sipcore@ietf.org
> > > 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 [john.elwell@siemens-enterprise.com]
> > > Sent: Friday, August 13, 2010 3:19 AM
> > > To: Winterbottom, James; sipcore@ietf.org
> > > 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:James.Winterbottom@andrew.com]
> > > > Sent: 12 August 2010 09:27
> > > > To: Elwell, John; sipcore@ietf.org
> > > > 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: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On
> > > > Behalf Of Elwell, John [john.elwell@siemens-enterprise.com]
> > > > Sent: Thursday, August 12, 2010 3:21 AM
> > > > To: sipcore@ietf.org
> > > > 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
> > > > sipcore@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > >
> > > _______________________________________________
> > > sipcore mailing list
> > > sipcore@ietf.org
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >
> >
>