RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Fri Jul 27 2007 - 11:23:58 EDT

I'm not necessarily disagreeing. If we're arguing for simplicity, and
eliminating any data with the URI itself (meta data) then okay. The
try-and-fail paradigm would be all you get.

I would rather have an expiry on the URI than a new mechanism in the LCP, so
if we need something, than I think expiry on the URI is preferable.

Of course it would have to be optional.

And yes, in Geopriv terms, a watcher asks a LS for the targets location, and
gets the URI in response.

Brian

> -----Original Message-----
> From: Roger Marshall [mailto:RMarshall@telecomsys.com]
> Sent: Friday, July 27, 2007 11:13 AM
> To: Brian Rosen; Winterbottom, James; Hannes Tschofenig
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
>
> The Presence architecture, we don't see the recipient really asking the
> target for its (the target's) location, it's the recipient asking the
> Location Server (LS) for the target's location, (though it may be the
> case that the target==LS). Does anyone disagree with how this is
> framed?
>
> After thinking about it, I'm leaning toward supplying nothing in terms
> of metadata, (ref. Hannes' earlier response, "where does one draw the
> line"), so there is only a URI. Therefore, the expiry requirement would
> go away. Perhaps a new requirement on the shoulders of the LCP or Deref
> protocol to let the LS/LIS know that location updates should be kept
> current.
>
> How does the recipient know to ask again? At 'need' time - try the
> location URI, if it is expired, ask for a new one (a LCP action,
> followed by a Deref action). This is simpler, and admittedly, more
> risky in terms of timing. Still, it should be the LS that keeps tabs on
> the target's current location.
>
> -roger marshall.
>
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Friday, July 27, 2007 7:55 AM
> > To: 'Winterbottom, James'; 'Hannes Tschofenig'
> > Cc: Roger Marshall; geopriv@ietf.org
> > Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
> >
> > The recipient.
> >
> > You give me a URI. How do I know when to ask you for a new one?
> >
> > Essentially all of the mechanisms we have for you to give me
> > a URI involve me asking (i.e. pull from target to watcher).
> > There are no push mechanisms for a URI. There is a push
> > (i.e. the presence subscription) of the value.
> >
> > So, since it is the watcher that asks the target for the URI,
> > how does it know when to ask for another one?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Friday, July 27, 2007 10:28 AM
> > > To: Brian Rosen; Hannes Tschofenig
> > > Cc: Roger Marshall; geopriv@ietf.org
> > > Subject: RE: [Geopriv] RE:
> > draft-marshall-geopriv-lbyr-requirements-01
> > >
> > > Brian,
> > >
> > > Do you mean the Recipient or the Target?
> > >
> > > I don't think that the Recipient should be able to ask anyone other
> > > than the Target for a new location URI. So again providing that the
> > > Target knows when a location URI is about to expire he/she can take
> > > the necessary actions to either continue to make location
> > available to
> > > a Recipient or simply allow it to run out.
> > >
> > > Cheers
> > > James
> > >
> > >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Thursday, July 26, 2007 8:17 PM
> > > To: 'Winterbottom, James'; 'Hannes Tschofenig'
> > > Cc: Stark, Barbara; 'Roger Marshall'; geopriv@ietf.org
> > > Subject: RE: [Geopriv] RE:
> > draft-marshall-geopriv-lbyr-requirements-01
> > >
> > > Okay, but how does the recipient know when it has to ask
> > for a new URI?
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > > Sent: Thursday, July 26, 2007 8:10 PM
> > > > To: Hannes Tschofenig; Brian Rosen
> > > > Cc: Stark, Barbara; Roger Marshall; geopriv@ietf.org
> > > > Subject: RE: [Geopriv] RE:
> > > > draft-marshall-geopriv-lbyr-requirements-01
> > > >
> > > >
> > > > I guess I would see this type of URI as a special case
> > rather than
> > > > the norm.
> > > > I am not sure that I necessarily want to advertise to people how
> > > > long
> > > I am
> > > > prepared to allow them to retireve my location.
> > > >
> > > > Cheers
> > > > James
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > > Sent: Thu 7/26/2007 7:07 PM
> > > > To: Brian Rosen
> > > > Cc: Winterbottom, James; 'Stark, Barbara'; 'Roger Marshall';
> > > > geopriv@ietf.org
> > > > Subject: Re: [Geopriv] RE:
> > > > draft-marshall-geopriv-lbyr-requirements-01
> > > >
> > > > Hi Brian
> > > >
> > > > Brian Rosen wrote:
> > > > > I think we need a mechanism to define what the client
> > would like
> > > > > the duration to be.
> > > >
> > > > See
> > > >
> > >
> > http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-conte
> > > xt
> > > -
> > > > 00.txt
> > > >
> > > > > I think the LCP needs to return what the duration is.
> > > > > I'm not sure we need to convey the time.
> > > > >
> > > > See
> > > > http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-http-location-
> > > > delivery/
> > > >
> > > > > The request is a parameter to HELD. The return could be a
> > > > > parameter
> > > on
> > > > the
> > > > > URI itself, e.g.
> > > > http:6eddet665s6@lis.example.com;expires:07jun07_10:39:00
> > > > >
> > > > >
> > > > That's the meta-data I was talking about in a previous mail.
> > > > This is obviously an option and might be useful for the Location
> > > > Recipient.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Winterbottom, James
> > [mailto:James.Winterbottom@andrew.com]
> > > > >> Sent: Wednesday, July 25, 2007 4:22 PM
> > > > >> To: Stark, Barbara; Roger Marshall; geopriv@ietf.org
> > > > >> Subject: RE: [Geopriv] RE:
> > > draft-marshall-geopriv-lbyr-requirements-01
> > > > >>
> > > > >>
> > > > >> Hi Barbara,
> > > > >>
> > > > >> HELD supports part 1 now, in that it provides a lifetime
> > > > >> parameter
> > > back
> > > > to
> > > > >> the Target saying, hey these URIs are good for this
> > period of time.
> > > > >>
> > > > >> Isn't sending that time on the end Recipient kind of an
> > > > >> application
> > > or
> > > > >> conveyance thing, rather than a problem with the dereference
> > > protocol
> > > > or
> > > > >> the URI specification?
> > > > >>
> > > > >> Cheers
> > > > >> James
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Stark, Barbara [mailto:bs7652@att.com]
> > > > >> Sent: Wed 7/25/2007 2:27 PM
> > > > >> To: Winterbottom, James; Roger Marshall; geopriv@ietf.org
> > > > >> Subject: RE: [Geopriv] RE:
> > > draft-marshall-geopriv-lbyr-requirements-01
> > > > >>
> > > > >> OK. I can see that. But then there will need to be a
> > parameter to
> > > let
> > > > >> the requestor know what the expiration is, especially of the
> > > requestor
> > > > >> didn't specify a value. Or if the requestor did
> > specify a value,
> > > but
> > > > the
> > > > >> server used a different (probably shorter) value, according to
> > > > >> its rules.
> > > > >>
> > > > >> Would it be ok to specify a format for putting an
> > expiration (or
> > > number
> > > > >> of uses) in the URI, for the case where I do want to send that
> > > > >> info
> > > on
> > > > >> with the URI? But just not require it?
> > > > >> Barbara
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Winterbottom, James
> > [mailto:James.Winterbottom@andrew.com]
> > > > >> Sent: Wednesday, July 25, 2007 2:54 PM
> > > > >> To: Stark, Barbara; Roger Marshall; geopriv@ietf.org
> > > > >> Subject: RE: [Geopriv] RE:
> > > draft-marshall-geopriv-lbyr-requirements-01
> > > > >>
> > > > >> I am happy with one and three, but I don't like 2.
> > > > >> The validity of the location URI should be governed by
> > whether it
> > > works
> > > > >> or not. If I create a temporary URI for example, I
> > might not want
> > > to
> > > > >> tell you that I am only prepared to give you a URI
> > that is valid
> > > for 2
> > > > >> minutes.
> > > > >>
> > > > >> I can envisage other cases too. For example I might want to a
> > > provide
> > > > >> pawn-ticket location URI which is restricted to single
> > use only.
> > > > >> In
> > > > this
> > > > >> case a time may not be appropriate.
> > > > >>
> > > > >> Cheers
> > > > >> James
> > > > >>
> > > > >>
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Stark, Barbara [mailto:bs7652@att.com]
> > > > >>> Sent: Thursday, 26 July 2007 4:49 AM
> > > > >>> To: Roger Marshall; Winterbottom, James; geopriv@ietf.org
> > > > >>> Subject: RE: [Geopriv] RE:
> > > draft-marshall-geopriv-lbyr-requirements-01
> > > > >>>
> > > > >>> I don't think it quite satisfies. The "Location Reference
> > > mechanism"
> > > > >>> isn't really defined, but it seems to mean all the components
> > > involved
> > > > >>> in LbyR, as a whole. The term seems to imply the Location
> > > > >>>
> > > > >> Configuration
> > > > >>
> > > > >>> protocol, plus whatever the server does to come up with a
> > > reference,
> > > > >>> plus the reference protocol.
> > > > >>>
> > > > >>> What I think is needed, is that (1) the server must be able to
> > > > >>>
> > > > >> associate
> > > > >>
> > > > >>> an expiration time with the URI, (2) that expiration
> > time really
> > > needs
> > > > >>> to be included in the URI itself, so that whoever gets the URI
> > > also
> > > > >>> knows when it will expire [everyone who get the URI needs to
> > > > >>> know
> > > when
> > > > >>> it will expire, and trying to express it in a
> > separate parameter
> > > is
> > > > >>> ugly], and [3] it's desirable for the Location Configuration
> > > protocol
> > > > >>>
> > > > >> to
> > > > >>
> > > > >>> be able to express a preference for that expiration value. In
> > > > >>> the absence of the LCP specifying an expiration, the server
> > > > >>> should be
> > > able
> > > > >>> to assign a default value. What that default is,
> > doesn't need to
> > > be
> > > > >>> specified, since different networks have different
> > needs for how
> > > long
> > > > >>> this might be.
> > > > >>>
> > > > >>> I don't think that we should say "the LCP MUST be able to
> > > > >>> express
> > > an
> > > > >>> expiration value", but it should definitely be recommended.
> > > > >>> Barbara
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Roger Marshall [mailto:RMarshall@telecomsys.com]
> > > > >>> Sent: Wednesday, July 25, 2007 12:43 PM
> > > > >>> To: Winterbottom, James; geopriv@ietf.org
> > > > >>> Subject: [Geopriv] RE:
> > > > >>> draft-marshall-geopriv-lbyr-requirements-01
> > > > >>>
> > > > >>> James:
> > > > >>> This comment wasn't posted to the list, so I've added
> > geopriv in
> > > the
> > > > >>>
> > > > >> to:
> > > > >>
> > > > >>> address.
> > > > >>>
> > > > >>> Based on your comment about the requirement applying to the
> > > > >>>
> > > > >> 'protocol',
> > > > >>
> > > > >>> I had already changed Rq4 as follows:
> > > > >>>
> > > > >>> Rq4. Location Reference Expiration: The Location
> > Reference
> > > > >>> mechanism MUST provide a way to limit the
> > validity of that
> > > > >>> reference (and SHOULD also provide a way to extend or
> > > shorten
> > > > >>>
> > > > >> the
> > > > >>
> > > > >>> validity period).
> > > > >>>
> > > > >>> Does this satisfy?
> > > > >>>
> > > > >>> Sorry for the delayed response, and thanks.
> > > > >>>
> > > > >>> -roger marshall.
> > > > >>>
> > > > >>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Winterbottom, James
> > > > >>>> [mailto:James.Winterbottom@andrew.com]
> > > > >>>> Sent: Monday, June 25, 2007 11:34 PM
> > > > >>>> To: Roger Marshall
> > > > >>>> Subject: draft-marshall-geopriv-lbyr-requirements-01
> > > > >>>>
> > > > >>>> Hi Roger,
> > > > >>>>
> > > > >>>> I have been looking through this document again and I am
> > > > >>>> struggling with requirement Rq4.
> > > > >>>>
> > > > >>>> "Rq4. Location Reference Expiry: The dereference
> > protocol MUST
> > > > >>>> support specification of a finite period of
> > validity for
> > > > >>>> the LRI.
> > > > >>>>
> > > > >>>> Motivation: Location references are not intended to
> > > represent
> > > > >>>>
> > > > >> a
> > > > >>
> > > > >>>> location forever, and the identifier
> > eventually may need
> > > > >>>> to
> > > be
> > > > >>>> recycled, or may be subject to a specific window of
> > > validity,
> > > > >>>> after which the location reference fails to yield a
> > > location,
> > > > >>>>
> > > > >> or
> > > > >>
> > > > >>>> the location is determined to be kept confidential. An
> > > expiry
> > > > >>>> timer for a location reference ensures that
> > the location
> > > > >>>> reference
> > > > >>>> becomes invalid based on configuration."
> > > > >>>>
> > > > >>>> It seems to me that this is not a requirement of the
> > > > >>>> dereference protocol, but a requirement on the LCP,
> > and on the
> > > > >>>> LCS. The LCS needs to be able to Limit the life time of a
> > > > >>>> location URI, and needs to be able to communicate this
> > > > >>>> restriction to the End-Point over the LCP. There is a
> > > > >>>> requirement on the LCS to reject any location request to a
> > > > >>>> location URI that has expired. But this there is no
> > requirement
> > > > >>>> that I can see for the location URI or the
> > dereference protocol
> > > > >>>> to support a validity period. I think I would also need
> > > > >>>> convincing that there is a need for the Target to be able to
> > > > >>>> convey the reference life time to the
> > > > >>>>
> > > > >> Recipient.
> > > > >>
> > > > >>>> A couple of other nits:
> > > > >>>>
> > > > >>>> The document should now probably refer to the HELD
> > specification.
> > > > >>>> It probably shouldn't refer to the DHCP civil draft
> > for civic
> > > > >>>> information but rather the revised civic draft.
> > > > >>>>
> > > > >>>> The notion of a well-formed PIDF-LO (Rq8) is not defined in
> > > > >>>> this document, but in other documents it refers to one that
> > > > >>>> follows the rules outlines in the PIDF-LO profile draft.
> > > > >>>>
> > > > >>>>
> > > > >>>> Cheers
> > > > >>>> James
> > > > >>>>
> > --------------------------------------------------------------
> > > > >>>> ----------------------------------
> > > > >>>> 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]
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>> The information contained in this message may be privileged
> > > > >>> and/or confidential. If you are not the intended recipient, or
> > > responsible
> > > > >>>
> > > > >> for
> > > > >>
> > > > >>> delivering this message to the intended recipient,
> > any review,
> > > > >>> forwarding, dissemination, distribution or copying of this
> > > > >>>
> > > > >> communication
> > > > >>
> > > > >>> or any attachment(s) is strictly prohibited. If you have
> > > > >>> received
> > > this
> > > > >>> message in error, please so notify the sender immediately, and
> > > delete
> > > > >>>
> > > > >> it
> > > > >>
> > > > >>> and all attachments from your computer and network.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> 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]
> > > > >>
> > > > >>
> > > > >> *****
> > > > >>
> > > > >> The information transmitted is intended only for the person or
> > > entity
> > > > to
> > > > >> which it is addressed and may contain confidential,
> > proprietary,
> > > and/or
> > > > >> privileged material. Any review, retransmission,
> > dissemination or
> > > other
> > > > >> use of, or taking of any action in reliance upon this
> > information
> > > by
> > > > >> persons or entities other than the intended recipient is
> > > prohibited. If
> > > > >> you received this in error, please contact the sender
> > and delete
> > > the
> > > > >> material from all computers. GA621
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > >
> > ----------------------------------------------------------------------
> > > -
> > > > ---
> > > > >> ----------------------
> > > > >> 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
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > ----------------------------------------------------------------------
> > > --
> > > --
> > > > ----------------------
> > > > 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
Received on Fri, 27 Jul 2007 11:23:58 -0400

This archive was generated by hypermail 2.1.8 : Fri Jul 27 2007 - 11:24:09 EDT