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


_______________________________________________
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