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

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Fri Jul 27 2007 - 13:28:12 EDT

Barbara:
The use cases you describe are good ones. To reiterate,

1. ) The recipient (not the target per se, in the Pres Arch) requests -
via the LCP - an (LbyR) location URI w/expiry parameters (e.g., good
from now until noon).
2. ) The recipient receives the location URI without expiry info [this
is what this thread proposed].
3. ) The recipient shares the location URI (by whatever means) without
expiry info.

In order for this to happen, the LCP has to support the expiry info
request.

-roger marshall.

> -----Original Message-----
> From: Stark, Barbara [mailto:bs7652@att.com]
> Sent: Friday, July 27, 2007 10:14 AM
> To: Roger Marshall; Winterbottom, James; Brian Rosen; Hannes
> Tschofenig
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
>
> I guess I'm fuzzy on this too. I certainly had hoped that the
> document would address LbyR requirements for LCP and "LDP".
> If it does address the LbyR for LCP aspect, then I think it's
> very important that there exist a requirement that the Target
> be able to request a specific expiration value from the LIS,
> and that the LIS be able to respond with an expiration value
> (in case it decided to use a value different than the requested one).
>
> I can see the case where my boss asks me for a LbyR, in case
> he needs to catch up with me that day; so I send him one that
> lasts the rest of the work day. And then someone wants to
> join me for lunch, so I send him one that will last till just
> after noon (so he can find me when he gets there). I don't
> think there's any way a static server policy can meet this
> need. And I don't think it's reasonable to expect me to go in
> and play with my personal policy, just because I need a
> specific expiration value for the person I'm getting ready to
> send a reference to right now.
>
> Barbara
>
> -----Original Message-----
> From: Roger Marshall [mailto:RMarshall@telecomsys.com]
> Sent: Friday, July 27, 2007 12:42 PM
> To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
>
> James:
>
> Since this is the draft which talks about the location URI, I
> don't see how I can state what a Rule Maker MUST do, but I do
> agree with the idea of putting text in this draft that says,
> 'it is the expectation that...', and so forth.
>
> General Question to the work group:
>
> I'm still a little fuzzy on whether a draft such as this one
> for LbyR is restricted to only talking about LbyR
> requirements for the LCP, LbyR reqs for the Location Deref
> protocol, or should it have a broader reach, to require what
> must happen overall for an LbyR Mechanism to work.
>
> Another question to the wg:
>
> Any objection to coining a new acronym for Location
> Dereference Protocol, 'LDP', since it goes nicely with LCP?
> [realizing there is already 'Label Distribution Protocol',
> (LDP) from MPLS]
>
> -roger marshall.
>
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Friday, July 27, 2007 9:27 AM
> > To: Roger Marshall; Brian Rosen; Hannes Tschofenig
> > Cc: geopriv@ietf.org
> > Subject: RE: [Geopriv] RE:
> draft-marshall-geopriv-lbyr-requirements-01
> >
> > Hi Roger,
> >
> > I am okay with the requirement disappearing if we put a
> statement in
> > the text somewhere that essentially says that the rule-make
> must have
> > a means to see when a location URI will expire and may additionally
> > have controls allowing it to change (shorten or lengthen)
> URI expiry
> > times including the ability to void a URI.
> >
> > I think that this stresses that URIs may expire and that
> expiry may be
> > controlled through deliberate policy.
> >
> > Cheers
> > James
> >
> >
> > -----Original Message-----
> > From: Roger Marshall [mailto:RMarshall@telecomsys.com]
> > Sent: Fri 7/27/2007 11:08 AM
> > To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
> > Cc: geopriv@ietf.org
> > Subject: RE: [Geopriv] RE:
> draft-marshall-geopriv-lbyr-requirements-01
> >
> > The proposal currently on the table is to delete the following
> > requirement in the next draft version:
> >
> > 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).
> >
> > 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.
> >
> >
> > The justification for deleting the above altogether, is in order to
> > avoid metadata which may not be desired in some cases,
> revert to an,
> > 'if location URI is expired (using Deref), then ask for a new one'
> > approach (via LCP).
> >
> >
> > -roger marshall.
> >
> > > -----Original Message-----
> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > > Sent: Friday, July 27, 2007 8:48 AM
> > > To: Brian Rosen; Roger Marshall; Hannes Tschofenig
> > > Cc: geopriv@ietf.org
> > > Subject: RE: [Geopriv] RE:
> > draft-marshall-geopriv-lbyr-requirements-01
> > >
> > > Hi Brian,
> > >
> > > I assume you mean the watcher asks the LS for a Target's
> > location and
> > > gets a PIDF-LO. I would be less keen for you to ask my
> > presence server
> > > for my location and get the URI to the LIS serving me currently.
> > >
> > > I certainly think that we can have a URI profile that the
> > rule-maker
> > > can explicitly request to contain an expiry time.
> > > But I want this to be an explicit decision on the part of the
> > > rule-maker.
> > >
> > > In the interests of moving forward, I think that Roger's
> > proposal is
> > > fine.
> > >
> > > Cheers
> > > James
> > >
> > >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Fri 7/27/2007 10:23 AM
> > > To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'
> > > Cc: geopriv@ietf.org
> > > Subject: RE: [Geopriv] RE:
> > draft-marshall-geopriv-lbyr-requirements-01
> > >
> > > 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-con
> > > > > te
> > > > > > 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-locatio
> > > > > > > n-
> > > > > > > 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]
> > > > >
> > > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------------------------------
> > > 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
>
> *****
>
> 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. GA623
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 27 Jul 2007 10:28:12 -0700

This archive was generated by hypermail 2.1.8 : Fri Jul 27 2007 - 13:28:27 EDT