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

From: Drage, Keith \(Keith\) ^lt;drage@lucent.com>
Date: Thu Jul 27 2006 - 09:13:40 EDT

(as individual)

I am not sure I understand your argument here.

As far as I understand, and in addition to any other constraints, any
protocol used as a result of the reference to carrt location must be a
location using protocol in and pass the IETF (as policed by GEOPRIV)
privacy provisions on location.

In the absence of any other normative document by GEOPRIV that
normatively lists those protocols, the dereferencing protocol
specification (currently specified in sip-location-conveyance) must
normatively indicate that list. Whether it does it by ABNF or text is
academic - they are both normative specifications, and they both need an
RFC to update them.

I believe we do have a requirement that the dereferencing protocol
entity MUST NOT use a protocol that is not a location using protocol.

Regards

Keith

> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: 27 July 2006 00:31
> To: Abbott, Nadine B; Brian Rosen; sip@ietf.org
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
>
> Brian,
>
> I don't care if you don't mention how to de-reference URI
> types other than sip/sips/cid/pres in the document or not.
> But I do not want the schema artificially constrained to
> exclude URI types such as HTTP. There is clearly not
> consensus to justify this exclusion, so please leave schema
> unchanged and make your recommendations in the text.
>
> Cheers
> James
>
>
>
> -----Original Message-----
> From: Abbott, Nadine B [mailto:nabbott@telcordia.com]
> Sent: Thursday, 27 July 2006 7:44 AM
> To: Brian Rosen; sip@ietf.org
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
>
> Brian,
>
> Actually, I was thinking that in other industry work which is
> trying to leverage and provide transitional strategies to
> migrate to using SIP to support emergency services, the and
> long-term solutions that we have defined assume a capabity to
> provide location-by-reference. I think it would be very
> useful to have this defined in a standard SIP header
> mechanism in such a way that we need not redefine migratory
> solutions that have begun to be implemented. If an HTTPS URI
> can be used as the location-by-reference, this will be
> helpful, I think.
>
> I don't understand your urgency to make location-by-reference
> only an all-sip-all-the-time thing.
> And from all the other emails on this topic, it didn't seem
> to me that there is a consensus to do this.
>
> Nadine
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, July 26, 2006 3:15 PM
> To: Abbott, Nadine B; sip@ietf.org
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
>
> 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:nabbott@telcordia.com]
> > Sent: Wednesday, July 26, 2006 2:14 PM
> > To: sip@ietf.org
> > Cc: geopriv@ietf.org
> > 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:Brian.Rosen@neustar.biz]
> > Sent: Tuesday, July 25, 2006 1:38 PM
> > To: sip@ietf.org
> > Cc: geopriv@ietf.org
> > 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
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 27 Jul 2006 15:13:40 +0200

This archive was generated by hypermail 2.1.8 : Thu Jul 27 2006 - 09:13:58 EDT