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

Hi Brian,

are you talking about the end host adding a location-by-reference into 
the SIP header or a proxy doing so?

In any case I don't understand your objection against the usage of HTTP 
and your preference for SIP/SIPS/PREZ?

Ciao
Hannes

Brian Rosen wrote:
> Nadine
> 
> Are you saying that it's your opinion sip-location-conveyance MUST
> define an HTTP dereference procedure?
> 
> If you do, why?  What is the use-case or requirement?
> 
> Would it not be pretty reasonable to require a separate document that
>  defines a location-by-reference mechanism, protocol, and geopriv
> "using protocol" analysis?  If that document specifically extended
> what was allowed in the location header, would that not be
> reasonable?
> 
> I think we have to include "A" dereference mechanism in the 
> location-conveyance document.  It seems just including sip/sips/prez
> is a reasonable, all-sip-all-the-time approach IN THIS DOCUMENT.
> That certainly does not preclude another document describing another
> way.
> 
> Doesn't it seem just a little weird to have a sip-location-conveyance
>  document describing any kind of http based location conveyance 
> (de-reference) protocol, especially one created whole cloth without
> any other parts?
> 
> Doesn't it seem in keeping with the geopriv approach that in order to
> have another "using protocol" it has to have a geopriv review?  That
> is what leads to restricting the URI schemes.  Would you prefer to
> let it be wide open, so any protocol anyone thinks about can be used
> with the location header?  I can't see geopriv going along with that.
> We're going to make it a one line ABNF to add a new scheme to the
> list of allowed schemes.
> 
> It seems to me that if it's desired to define some bare-bones HTTP
> location by reference protocol, then that should be a separate
> document, which can easily extend the allowable schemes in the
> Location header.  I'm not sure it might be better to define ALL of
> that in the L7 protocol, but I wouldn't be opposed to a simple "raw
> GET" RFC as long as it got a full geopriv review. I just don't see
> where it makes any sense to force that into a sip document.
> 
> Brian
> 
> 
>> -----Original Message----- From: Abbott, Nadine B
>> [mailto:[email protected]] Sent: Wednesday, July 26, 2006 2:14
>> PM To: [email protected] Cc: [email protected] Subject: RE: [Geopriv]
>> Consensus on changes to location-conveyance
>> 
>> 
>> I don't agree that there is a consensus to preclude the use of
>> HTTP. I would favor not placing your proposed restriction on the
>> URI scheme for expressing a location reference in the SIP location
>> conveyance draft; or at least including HTTP as a valid
>> location-reference URI type.
>> 
>> Regards, Nadine Abbott
>> 
>> -----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.
>> 
>> 2. Dereferencing location-by-reference.  We had initially proposed
>> to document a process to use a raw HTTP(S) Get to dereference.
>> There was a lot of discussion, and then I made a new proposal, see
>> item 6.
>> 
>> 3. We proposed to allow a Reason header with a 424 Bad Location 
>> response.  This seems to be acceptable to the WG.  Geopriv will
>> create and populate the registry in a separate draft.
>> 
>> 4. We proposed to explicitly allow hop-by-hop TLS security for
>> location when the endpoint wished to allow routing based on
>> location.  We further proposed to interpret "Do not Distribute"
>> flags as allowing sending of the location to the routing database
>> (LoST for example).  Hannes pointed out that there was a proposal
>> to allow two Location headers, one of which could be used for
>> routing and another for onward forwarding to the recipient.
>> Hannes' message seemed to agree that "Do not distribute" would
>> allow sending of the location to the routing-by-location database, 
>> but would obligate the proxy that did that to remove the location
>> before it forwarded the message.  There were no other messages on
>> this thread. We conclude that allowing hop-by-hop security for
>> location based routing is acceptable, and Do Not Distribute DOES
>> allow forwarding to a routing database, but requires that the proxy
>> doing the location based route to remove the location it uses for
>> that purpose.
>> 
>> 5. We proposed to create a parameter and a registry to distinguish 
>> multiple ways to dereference a location where HTTP(S) was the
>> transport. Resolution of this issue depends on resolution of issue
>> 6.
>> 
>> 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.
>> 
>> If this does not reflect your position, please speak up now.
>> 
>> Brian
>> 
>> _______________________________________________ Geopriv mailing
>> list [email protected] 
>> https://www1.ietf.org/mailman/listinfo/geopriv
>> 
>> _______________________________________________ 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