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

I have no problem with pidf/pidf-lo/presence.

I have no problem with a ua placing a uri pointing to their presence service
in a header of a sip invite.

Context check:  We're discussing a sip invite (assumed pointed to emergency
service) that arrives at a proxy with zero location information.

I'm the only one that has a problem with any (visited) proxy/LIS creating a
uri that can be de-referenced by anyone without regard to user
security/privacy rules?

-Marc-





> -----Original Message-----
> From: Peterson, Jon [mailto:[email protected]] 
> Sent: Tuesday, July 25, 2006 4:42 PM
> To: Andrew Newton; Rosen, Brian
> Cc: [email protected]; [email protected]; Marc Linsner
> Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to 
> location-conveyance
> 
> 
> 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:[email protected]]
> > Sent: Tuesday, July 25, 2006 1:05 PM
> > To: Rosen, Brian
> > Cc: [email protected]; [email protected]; 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:[email protected]]
> > >> Sent: Tuesday, July 25, 2006 3:29 PM
> > >> To: Rosen, Brian; [email protected]
> > >> Cc: [email protected]
> > >> Subject: RE: [Geopriv] Consensus on changes to 
> location-conveyance
> > >>
> > >> In-line.....
> > >>
> > >>> -----Original Message-----
> > >>> From: Rosen, Brian [mailto:[email protected]]
> > >>> Sent: Tuesday, July 25, 2006 1:38 PM
> > >>> To: [email protected]
> > >>> Cc: [email protected]
> > >>> 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 
> > > [email protected] for questions on current sip Use 
> > > [email protected] for new developments on the application of sip
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email protected]
> > 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip