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

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Thu Jul 26 2007 - 19:42:57 EDT

I think we need a mechanism to define what the client would like the
duration to be. I think the LCP needs to return what the duration is.
I'm not sure we need to convey the time.

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

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
Received on Thu, 26 Jul 2007 19:42:57 -0400

This archive was generated by hypermail 2.1.8 : Thu Jul 26 2007 - 19:43:20 EDT