RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Mon Nov 26 2007 - 16:55:37 EST

Actually "location conveyance" is about any application protocol sending a piece of location information (value or reference) from one peer to another for some purpose within the scope that application. To this extent the existence of the location information is peripheral to the fact of the application protocol. Conveyance is between any two entities - it doesn't matter if the location represents either signalling peer, the location of some other entity or, indeed, whether it's describing the location of a specific entity at all. Location retrieval on the other hand is about the process of one signalling peer specifically asking for the location of some target. In this case the location information is the specific subject of the signalling exchange and there is no other application context in which it is subject to interpretation. Doing a dereference is definitely a location retrieval and trying to regard it as something else is a slippery slope to confusion. SIP conveyance may have been written with the intention of it supporting a conveyance context. As soon as it's used to do an actual location acquisition request, then it's being used for location retrieval. Neither the name of the spec nor the intent of the writer can somehow change that fact. Cheers, Martin -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, 27 November 2007 8:04 AM To: James M. Polk; Hannes Tschofenig; Marc Linsner Cc: geopriv@ietf.org Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70 I'm James but to me your response isn't clear at all. I shall go through it and ask questions if you don't mind. By your definition, if the reference is a held URI, then dereference is retrieval because it is being sort > > >I agree that the area is a little grey though. > > You are wrong, and this isn't grey at all. SIP Location Conveyance, > the document, *DOES*NOT* define how to seek someone else's location, EVER. > [AJW] So, by this statement does it allow it? If you send a SIP or pres location URI to someone, and they can subscribe to that location URI then you do define how to acquire someone else's location. Indeed I would argue that this is a planned use. If this is not to be allowed then you should have explicit statements in the document saying that the subscription mechanism is only applicable to a URI that references your own location. > Location-by-reference has location sent to the intended Location > Recipient ONCE. [AJW] I don't understand this statement at all. Are you saying that all location URIs may only be used once? That all only one notify is ever sent to the recipient? If SIP or Presence is used for dereferencing, this > occurs in the NOTIFY request, which is CONVEYING location to the > Location Recipient. [AJW] I can equally argue that a NOTIFY should not be sent to me unless I subscribe for it first, which is an explicit request to "retrieve" location. This is the only time actual location is in any > message, and with an LbyR, it is sent indirectly in the initial > request (or UPDATE), but it is still SENT. > [AJW] I think that this is saying that sending a location URI is conveyance. I fully agree with this statement. > I'm not sure how much clearer I, as the document author, can state this. > > I don't care what NENA (no offense), or any other organization says > in this regard. The document is about conveying which, in English, > this means sending out or transmitting or telling, not seeking and > learning. [AJW] Yes, which would exclude a NOTIFY sent in response to at least the initial SUBSCRIBE since that involves a seek. It would also exclude HELD or HTTP URIs since they are always seek. Hopefully this clarifies the absurdity, and why conveyance in the wider community has come to mean from Target to Recipient, and retrieval is used from LIS to Recipient. > > To put this simply, Location Conveyance does not give rules for Alice > to seek and 'go get' Bob's location. It does provide rules for how > Alice tells Bob her location (by-value and by-reference). > > The SIP WG and Jon Peterson, the RAI AD, are very clear on this > separation of what SIP Conveyance is accomplishing. > > This document has been around for 4 years now, and it has said this > explicitly since IETF63 (Paris), without change. > > > > > BTW - I don't consider a dereference "location retrieval", that's > > > conveyance. > > > >----------------------------------------------------------------------- -- > ----------------------- > >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] ------------------------------------------------------------------------ ------------------------ 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 ------------------------------------------------------------------------------------------------ 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
Received on Mon, 26 Nov 2007 15:55:37 -0600

This archive was generated by hypermail 2.1.8 : Mon Nov 26 2007 - 16:56:43 EST