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

Hi Marc,

I agree with you.

I also think we should split the work into two parts as Henning 
suggested: One document covers the end host adds location-by-value (and 
potentially location-by-referenc) and another one that deals with the 
proxy doing something. The proxy case is far less understood as we know.

Ciao
Hannes

Marc Linsner wrote:
> 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
> 
> 


_______________________________________________
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