Re: [sipcore] Questions on location conveyance and dereferencing

"Winterbottom, James" <James.Winterbottom@andrew.com> Fri, 13 August 2010 09:13 UTC

Return-Path: <James.Winterbottom@andrew.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167123A68D7 for <sipcore@core3.amsl.com>; Fri, 13 Aug 2010 02:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.241
X-Spam-Level:
X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+B-ccWUkVLE for <sipcore@core3.amsl.com>; Fri, 13 Aug 2010 02:13:48 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 108513A68DA for <sipcore@ietf.org>; Fri, 13 Aug 2010 02:13:48 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:33204 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S217523Ab0HMJOY convert rfc822-to-8bit (ORCPT <rfc822; sipcore@ietf.org>); Fri, 13 Aug 2010 04:14:24 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 13 Aug 2010 04:14:24 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 13 Aug 2010 17:14:19 +0800
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 13 Aug 2010 17:14:19 +0800
Thread-Topic: [sipcore] Questions on location conveyance and dereferencing
Thread-Index: Acs591dqg6OyEIxSSSGOaw4Ja2Tz5gAALtKVADHnkYAAAE629wAAG7aQAADXHJAAAJUbYw==
Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AB@SISPE7MB1.commscope.com>
References: <A444A0F8084434499206E78C106220CA01C46B4FF1@MCHP058A.global-ad.net><5A55A45AE77F5941B18E5457ECAC81880120EB7D94A3@SISPE7MB1.commscope.com>, <A444A0F8084434499206E78C106220CA01C46B5547@MCHP058A.global-ad.net> <5A55A45AE77F5941B18E5457ECAC81880120EB7D94AA@SISPE7MB1.commscope.com> <3D3C75174CB95F42AD6BCC56E5555B4502E9BD6F@FIESEXC015.nsn-intra.net>, <A444A0F8084434499206E78C106220CA01C46B559B@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA01C46B559B@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: James.Winterbottom@andrew.com
Subject: Re: [sipcore] Questions on location conveyance and dereferencing
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 09:13:52 -0000

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