RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

"Peterson, Jon" <jon.peterson@neustar.biz> Tue, 25 July 2006 20:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tiz-0007cY-Mk; Tue, 25 Jul 2006 16:41:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Tiy-0007Zo-6a; Tue, 25 Jul 2006 16:41:52 -0400
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Tix-0001lW-R6; Tue, 25 Jul 2006 16:41:52 -0400
Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PKfjox008271; Tue, 25 Jul 2006 20:41:45 GMT
Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 16:41:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance
Date: Tue, 25 Jul 2006 16:41:31 -0400
Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F4511@stntexch03.cis.neustar.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance
Thread-Index: AcawJZpkqbGyCVnSTue1IO2WT/AgKAAAR94g
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Andrew Newton <andy@hxr.us>, "Rosen, Brian" <Brian.Rosen@neustar.biz>
X-OriginalArrivalTime: 25 Jul 2006 20:41:45.0189 (UTC) FILETIME=[BE25A150:01C6B02A]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc: sip@ietf.org, geopriv@ietf.org, Marc Linsner <mlinsner@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

As Brian points out, the whole point of using PIDF for location information was the similarity of the early defined use cases to the presence architecture. This certainly included use cases in which one wanted to fetch or subscribe to location information. Those operations require the existence of a reference, and that reference was commonly described as a URI, at the time. Lately, I think the idea of having a URI pointing to location information has become associated with a specific proposal (i.e. HELD), but clearly RFC4079 sketched out an architecture for using presence to acquire location information and it specifically mentions URIs as a way to refer to presence. 

There is no "hidden magic" in any of this. Subscribing to presence, and using URIs to indicate presence information, is exhaustively specified for SIP. PIDF-LO was designed to reuse all of that work and specifically not to require us to go out and reinvent everything in order to be able to refer to location information out in the network.

Basically, I support the direction re: bullet 6. I might further suggest that the CID URI scheme be permitted in the Location header, in order to be able to refer to MIME bodies included in SIP messages. I'm also neutral/favorable on using HTTP GET. But I think either of these URI schemes and their usage in the Location header could just as well be described in subsequent documents.

Jon Peterson
NeuStar, Inc,

> -----Original Message-----
> From: Andrew Newton [mailto:andy@hxr.us]
> Sent: Tuesday, July 25, 2006 1:05 PM
> To: Rosen, Brian
> Cc: sip@ietf.org; geopriv@ietf.org; Marc Linsner
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
> location-conveyance
> 
> 
> For the record, I agree with Brian.
> 
> -andy
> 
> On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote:
> 
> > When the original PIDF-LO RFC came out, location-by-reference was
> > defined.
> >
> > You have a URI.  You can exchange the URI for location.  There is a
> > protocol defined for that purpose (SIP SUBSCRIBE).  That is  
> > location by
> > reference.  It also serves as the location update mechanism, clearly
> > something we need.
> >
> > Some day, there may be other location URI references.  We don't  
> > need to
> > cover them in this draft.  The basic location by reference horse has
> > left the barn.  Were you planning on creating an RFC that 
> specifically
> > disallows a Subscribe on a sip/sips/pres URI to get location?    
> > THAT WAS
> > THE POINT OF MAKING IT PART OF A PIDF.
> >
> > I do think there is some value in defining a way to express a
> > location-by-reference aka presence URI which is not just the AoR.   
> > That
> > is one reason why I want to define the Location URI as being able to
> > contain a sip/sips/pres URI.  The purpose is to allow a UA or a  
> > proxy to
> > insert location where there is no association between the 
> identity of
> > the SIP user and the location.
> >
> > But that is all I think we need.
> >
> > We have a requirement for proxy insertion of location.  If 
> we disallow
> > location-by-reference (which I think is a good idea in general, but
> > futile in practice), then we would need something like the 
> Data URI to
> > support location insertion by proxy.  If we DO allow
> > location-by-reference, then it also serves to meet the location
> > insertion by proxy requirement, and we don't need the Data 
> URI.  We're
> > looking for a use case which requires proxy insertion by value, but
> > haven't heard one yet.
> >
> > You can make an argument that you can take the From:, assume it's an
> > AoR, and SUBSCRIBE to the presence of that AoR to get location,  
> > thus not
> > needing a Location header.  I really think letting the 
> Location header
> > specify an alternate presence URI is a good idea.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: Marc Linsner [mailto:mlinsner@cisco.com]
> >> Sent: Tuesday, July 25, 2006 3:29 PM
> >> To: Rosen, Brian; sip@ietf.org
> >> Cc: geopriv@ietf.org
> >> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
> >>
> >> In-line.....
> >>
> >>> -----Original Message-----
> >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
> >>> Sent: Tuesday, July 25, 2006 1:38 PM
> >>> To: sip@ietf.org
> >>> Cc: geopriv@ietf.org
> >>> Subject: [Geopriv] Consensus on changes to location-conveyance
> >>>
> >>> I have put out a number of emails on proposed changes to
> >>> location conveyance.  Some of them have sparked a number of
> >>> comments.  My summary of consensus on these issues is:
> >>>
> >>> 1. We proposed to explicitly disallow use of a Data URI,
> >>> which would allow specification of a Location-by-value in a
> >>> header.  There was a lot of list traffic on this, currently
> >>> in the state where Keith asked for a real use case for it.
> >>> So far, we don't see a use case that cannot be provided by
> >>> location-by-reference in a header.  If we don't get a good
> >>> use case, I think consensus is to disallow location-by-value
> >>> in a header.
> >>>
> >>
> >> I see a problem here.  Location-by-reference is nothing more than
> > 'magic
> >> happens here'!  Please point to a wg item documenting the
> >> location-by-reference mechanism.  How can you state the
> >> location-by-reference will cover all the use cases that 
> the Data URI
> > would
> >> when location-by-reference hasn't even been defined 
> anywhere?  You're
> >> loading up the magic with a lot of assumptions.  Location-by- 
> >> reference
> > is
> >> an
> >> individual submission as a solution to a set of requirements that
> > haven't
> >> been fleshed-out in geopriv.
> >>
> >> I believe that Henning/Hannes also recognized this issue, hence the
> >> suggestion of a Data URI.  Dismissing this suggestion based on an
> > already
> >> accepted non-existent mechanism seems like getting the 
> cart before  
> >> the
> >> horse.
> >>
> >> ..........snip
> >>
> >>> 6. We proposed to allow sip/sips and pres: in the location
> >>> header.  I later speculated that if we allow this, it forms a
> >>> simple way to do location-by-reference, and we could
> >>> eliminate the raw HTTP(S) Get proposal, with the parameter
> >>> and registry entirely.  There was some list traffic in favor
> >>> of this.  Martin Thompson is skeptical that SIP Presence
> >>> Subscribe/Notify is actually allowed as a geopriv "using
> >>> protocol".  Several of think that it is.  If we don't get any
> >>> more comments on this proposal, we will allow sip/sips and
> >>> pres, not have any
> >>> http(s) resolution text, and not propose a parameter and
> >>> accompanying registry.
> >>
> >> I certainly think it's more prudent to define the dereferencing
> > mechanism
> >> prior to making claims about the protocol.
> >>
> >> Do I believe location-by-reference will happen?  Probably, 
> but making
> >> assumptions about the mechanism now is quite premature.
> >>
> >> -Marc-
> >>
> >>>
> >>> If this does not reflect your position, please speak up now.
> >>>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip