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

Either.

I object to HTTP because there is no RFC I can reference that describes an
HTTP based geopriv using protocol.  I prefer SIP/SIPS/PRES because I can.

I don't think sip-location-conveyance should define an HTTP based geopriv
using protocol.

I don't object to a separate document that defines one.  I expect to see the
L7 protocol do that, for example.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]]
> Sent: Thursday, July 27, 2006 10:34 AM
> To: Brian Rosen
> Cc: 'Abbott, Nadine B'; [email protected]; [email protected]
> Subject: Re: [Sip] 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