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

From: "Roger Marshall" <[email-masked]>
Date: Wed, 25 Jul 2007 09:42:55 -0700

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:[email-masked]] 
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jul 2007 12:02:35 -0500

Hi Roger,

Just to make sure that I understand.
Is the requirement saying that the rule-maker has control over how long a reference will remain valid?

Cheers
James

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]]
Sent: Wed 7/25/2007 11:42 AM
To: Winterbottom, James; [email-masked]
Subject: RE: draft-marshall-geopriv-lbyr-requirements-01
 
James:

Does this satisfy?

-roger marshall.

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Jul 2007 14:48:47 -0400

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:[email-masked]] 
Sent: Wednesday, July 25, 2007 12:43 PM
To: Winterbottom, James; [email-masked]
Subject: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

James:

Does this satisfy?

-roger marshall.

> follows the rules outlines in the PIDF-LO profile draft.

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.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jul 2007 13:54:26 -0500

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

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, 26 July 2007 4:49 AM
> To: Roger Marshall; Winterbottom, James; [email-masked]
> Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Jul 2007 15:27:46 -0400

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:[email-masked]] 
Sent: Wednesday, July 25, 2007 2:54 PM
To: Stark, Barbara; Roger Marshall; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Cheers
James

> and all attachments from your computer and network.

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jul 2007 15:22:25 -0500

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: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 2:54 PM
To: Stark, Barbara; Roger Marshall; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Cheers
James

*****

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 25 Jul 2007 16:50:52 -0400

Are you suggesting that the SIP location conveyance draft then would
need the ability to specify the time left for the provided URI?
Barbara 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 4:22 PM
To: Stark, Barbara; Roger Marshall; [email-masked]
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: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 2:54 PM
To: Stark, Barbara; Roger Marshall; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Cheers
James

*****

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

*****

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. GA625

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jul 2007 23:19:30 +0200

Hi all,

you raised an interesting issue that came up already in the past 
already, namely:

"Do we need to attach meta-information to an LbyR?"

I recall that we had discussions regarding the ability and need to 
attach information about the type of location information that is being 
referenced.

One can easily imagine how to extend that stuff to virtually anything. 
Where do you stop?

Ciao
Hannes

Stark, Barbara wrote:
>> in LbyR, as a whole. The term seems to imply the Location
>>     
> Configuration
>   
>> What I think is needed, is that (1) the server must be able to
>>     
> associate
>   
>> ugly], and [3] it's desirable for the Location Configuration protocol
>>     
> to
>   
>> 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',
>   
>>       reference (and SHOULD also provide a way to extend or shorten
>>     
> the
>   
>>       validity period).
>>
>> Does this satisfy?
>>
>>>       Motivation: Location references are not intended to represent
>>>       
> a
>   
>>>       after which the location reference fails to yield a location,
>>>       
> or
>   
>>> Target to be able to convey the reference life time to the
>>>       
> Recipient.
>   
>>> A couple of other nits:
>>>
>> confidential. If you are not the intended recipient, or responsible
>>     
> for
>   
>> forwarding, dissemination, distribution or copying of this
>>     
> communication
>   
>> message in error, please so notify the sender immediately, and delete
>>     
> it
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Jul 2007 16:25:19 -0500

Sorry in advance for the short email response.

I guess the crux of my concern is that I don't understand why these questions are anymore pertinent to a location URI than they are to any other URI.

Cheers
James

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Wed 7/25/2007 4:19 PM
To: Stark, Barbara
Cc: Winterbottom, James; Roger Marshall; [email-masked]
Subject: Meta Data for LbyRs
 
Hi all,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Jul 2007 23:35:08 +0200

Right. All this stuff has very little todo with the LCP. Instead, this 
is a using protocol problem

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Jul 2007 19:42:57 -0400

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:[email-masked];expires:07jun07_10:39:00

Brian

> 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.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Jul 2007 02:07:17 +0200

Hi Brian

Brian Rosen wrote:
> duration to be.

See 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-00.txt

>   I think the LCP needs to return what the duration is.
See 
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-http-location-delivery/

> URI itself, e.g. http:[email-masked];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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 26 Jul 2007 19:09:57 -0500

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:[email-masked]]
Sent: Thu 7/26/2007 7:07 PM
To: Brian Rosen
Cc: Winterbottom, James; 'Stark, Barbara'; 'Roger Marshall'; [email-masked]
Subject: Re: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
 
Hi Brian

See 

See 

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Jul 2007 20:16:39 -0400

Okay, but how does the recipient know when it has to ask for a new URI?

Brian

> Sent: Thursday, July 26, 2007 8:10 PM
> To: Hannes Tschofenig; Brian Rosen
> Cc: Stark, Barbara; Roger Marshall; [email-masked]
> 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
> 
> 
> > URI itself, e.g.
> http:[email-masked];expires:07jun07_10:39:00
> >
> >
> >> -----------------------------------------------------------------------
> ---
> >> ----------------------
> >> -----------------------------------------------------------------------
> ---
> >> ----------------------
> >> [mf2]
> >>
> >>
> >>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Jul 2007 08:24:07 -0400

I don't think that a Target "must" advertise the expiration time. But
I'd definitely like to have the ability to do so. We shouldn't prevent
everyone from letting recipients know an expiration time, just because
some don't want to let recipients know.
Barbara 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 8:17 PM
To: 'Winterbottom, James'; 'Hannes Tschofenig'
Cc: Stark, Barbara; 'Roger Marshall'; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Brian

> > I think we need a mechanism to define what the client would like the
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context
-
> 00.txt
> > The request is a parameter to HELD.  The return could be a parameter
on
> >> Subject: RE: [Geopriv] RE:
draft-marshall-geopriv-lbyr-requirements-01
> >> conveyance thing, rather than a problem with the dereference
protocol
> >> Subject: RE: [Geopriv] RE:
draft-marshall-geopriv-lbyr-requirements-01
> >> didn't specify a value. Or if the requestor did specify a value,
but
> >> Subject: RE: [Geopriv] RE:
draft-marshall-geopriv-lbyr-requirements-01
> >>> Subject: RE: [Geopriv] RE:
draft-marshall-geopriv-lbyr-requirements-01
> -
> -
> >> ------------------------
> >> [mf2]
> >>
> >>
> >> *****
> >>
> >> The information transmitted is intended only for the person or
entity
--
--

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 09:28:04 -0500

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:[email-masked]] 
Sent: Thursday, July 26, 2007 8:17 PM
To: 'Winterbottom, James'; 'Hannes Tschofenig'
Cc: Stark, Barbara; 'Roger Marshall'; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Brian

on
protocol
but
entity

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jul 2007 10:55:16 -0400

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

> Sent: Friday, July 27, 2007 10:28 AM
> To: Brian Rosen; Hannes Tschofenig
> Cc: Roger Marshall; [email-masked]
> 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
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 10:12:32 -0500

Brian,

Comments in line:

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Fri 7/27/2007 9:55 AM
To: Winterbottom, James; 'Hannes Tschofenig'
Cc: 'Roger Marshall'; [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
 
The recipient.

[AJW] So if I get your point, you don't see how a Target can simply push a new URI to a Recipient?
      One way to indirectly address this is covered in the context management draft. This draft allows the rule-maker to extend the validity of a location URI. One other way is simply for the Recipient to try the URI and if it fails to request a new one. While this last case isn't optimal, and may not be satisfactory in some applications, I can imagine applications where it would be a reasonable solution.

The point I am trying raise here is that the control of this needs to remain with the rule-maker, and therefore providing the recipient with the expiry time must also be an explicit decision made by the rule-maker rather than being an explicit component of the URI.

Brian

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Jul 2007 08:13:09 -0700

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.

> Sent: Friday, July 27, 2007 7:55 AM
> 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
> 
> > 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
> > 
> > 
> > > 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
> > > Subject: Re: [Geopriv] RE: 
> > > > I think we need a mechanism to define what the client 
> would like 
> > > > the duration to be.
> > >
> > > See
> > >
> > 
> > > >> HELD supports part 1 now, in that it provides a lifetime 
> > > >> parameter
> > back
> > > to
> > > >> Isn't sending that time on the end Recipient kind of an 
> > > >> application
> > or
> > > >> OK. I can see that. But then there will need to be a 
> parameter to
> > let
> > > >> 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
> > > >> 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.
> > > >>
> > > >> pawn-ticket location URI which is restricted to single 
> use only. 
> > > >> In
> > > this
> > > >>> an expiration time with the URI, (2) that expiration 
> time really
> > needs
> > > >>> 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
> > > >>> 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
> > > >>> Subject: [Geopriv] RE: 
> > > >>> This comment wasn't posted to the list, so I've added 
> geopriv in
> > the
> > > >>>
> > > >> to:
> > > >>
> > > >>> address.
> > > >>>
> > > >>>>       support specification of a finite period of 
> validity for 
> > > >>>> the LRI.
> > > >>>>
> > > >>>>       location forever, and the identifier 
> eventually may need 
> > > >>>> to
> > be
> > > >>>>       timer for a location reference ensures that 
> the location 
> > > >>>> reference
> > > >>>> 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 
> 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 information contained in this message may be privileged 
> > > >>> and/or confidential. If you are not the intended recipient, or
> > responsible
> > > >>>
> > > >> for
> > > >>
> > > >>> or any attachment(s) is strictly prohibited. If you have 
> > > >>> received
> > this
> > > >> This message is for the designated recipient only and 
> may contain 
> > > >> privileged, proprietary, or otherwise private information.
> > > >> 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
> > > >> you received this in error, please contact the sender 
> and delete
> > the
> > > >> This message is for the designated recipient only and 
> may contain 
> > > >> privileged, proprietary, or otherwise private information.
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.
> > >
> > 
> ----------------------------------------------------------------------
> > ----
> > ----------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > 
> ----------------------------------------------------------------------
> > ----
> > ----------------------
> > [mf2]
> 
>

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Jul 2007 08:18:03 -0700

James:
I agree that the recipient/watcher should simply ask for a new location
URI if it finds the old one expired.  I think it is up to the Location
Server though, not the Rule Maker to orchestrate
getting/having/providing a fresh location and associated location URI -
while the Rule Maker does govern the allowance of such actions.

-roger marshall.

> Sent: Friday, July 27, 2007 8:13 AM
>       One way to indirectly address this is covered in the 
> context management draft. This draft allows the rule-maker to 
> extend the validity of a location URI. One other way is 
> simply for the Recipient to try the URI and if it fails to 
> request a new one. While this last case isn't optimal, and 
> may not be satisfactory in some applications, I can imagine 
> applications where it would be a reasonable solution.
> 
> The point I am trying raise here is that the control of this 
> needs to remain with the rule-maker, and therefore providing 
> the recipient with the expiry time must also be an explicit 
> decision made by the rule-maker rather than being an explicit 
> component of the URI.
> 
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jul 2007 11:23:58 -0400

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

> Sent: Friday, July 27, 2007 11:13 AM
> To: Brian Rosen; Winterbottom, James; Hannes Tschofenig
> Cc: [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 10:47:55 -0500

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:[email-masked]]
Sent: Fri 7/27/2007 10:23 AM
To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 10:52:17 -0500

Okay, that is fine, as long as the Target can also be a Location Server.

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]]
Sent: Fri 7/27/2007 10:18 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01
 
James:

-roger marshall.

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Jul 2007 09:08:53 -0700

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.

> Sent: Friday, July 27, 2007 8:48 AM
> To: Brian Rosen; Roger Marshall; Hannes Tschofenig
> Cc: [email-masked]
> 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.
> 
> 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.
> 
> 
> And yes, in Geopriv terms, a watcher asks a LS for the 
> targets location, and gets the URI in response.
> 
> Brian
> 
> > 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?
> > 
> > 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.
> > 
> > risky in terms of timing.  Still, it should be the LS that 
> keeps tabs 
> > on the target's current location.
> > 
> > -roger marshall.
> > 
> > 
> > > Essentially all of the mechanisms we have for you to give 
> me a URI 
> > > involve me asking (i.e. pull from target to watcher).
> > > So, since it is the watcher that asks the target for the URI, how 
> > > does it know when to ask for another one?
> > >
> > > Brian
> > >
> > > > 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
> http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-con
> > > te
> > > > xt
> > > > -
> > > > > 00.txt
> > > > >
> http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-http-locatio
> > > > > n-
> > > > > delivery/
> > > > >
> > > > > This is obviously an option and might be useful for 
> the Location 
> > > > > Recipient.
> > > > >
> > > > > Ciao
> > > > > Hannes
> > > > >
> > > > > > Brian
> > > > > >
> > > > > >
> > > > > >> the requestor know what the expiration is, 
> especially of the
> > > > requestor
> > > > > >> server used a different (probably shorter) value, 
> according 
> > > > > >> to its rules.
> > > > > >>
> > > > > >> of uses) in the URI, for the case where I do want to send 
> > > > > >> that info
> > > > on
> > > > > >> I can envisage other cases too. For example I 
> might want to a
> > > > provide
> > > > > >>> isn't really defined, but it seems to mean all the 
> > > > > >>> components
> > > > involved
> > > > > >>> What I think is needed, is that (1) the server 
> must be able 
> > > > > >>> to
> > > > > >>>
> > > > > >> associate
> > > > > >>
> > > > > >>> to be included in the URI itself, so that whoever 
> gets the 
> > > > > >>> URI
> > > > also
> > > > > >>> 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
> > > > > >>>       reference (and SHOULD also provide a way to 
> extend or
> > > > shorten
> > > > > >>>
> > > > > >> the
> > > > > >>
> > > > > >>>       validity period).
> > > > > >>>
> > > > > >>> Does this satisfy?
> > > > > >>>
> > > > > >>>>       the location is determined to be kept 
> confidential.  
> > > > > >>>> An
> > > > expiry
> > > > > >>>> 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:
> > > > > >>>>
> > > > > >>> and/or confidential. If you are not the intended 
> recipient, 
> > > > > >>> or
> > > > responsible
> > > > > >>>
> > > > > >> for
> > > > > >>
> > > > > >>> message in error, please so notify the sender 
> immediately, 
> > > > > >>> and
> > > > delete
> > > > > >>>
> > > > > >> it
> > > > > >>
> > > > > >> The information transmitted is intended only for 
> the person 
> > > > > >> or
> > > > entity
> > > > > to

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 11:26:35 -0500

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:[email-masked]]
Sent: Fri 7/27/2007 11:08 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

-roger marshall.

> > > Reference

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Jul 2007 09:41:55 -0700

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. 

> Sent: Friday, July 27, 2007 9:27 AM
> To: Roger Marshall; Brian Rosen; Hannes Tschofenig
> Cc: [email-masked]
> 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
> 
> 
> The proposal currently on the table is to delete the 
> following requirement in the next draft version:
> 
> the validity period).
> 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.
> 
> 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.
> > 
> rule-maker 
> > can explicitly request to contain an expiry time.
> > In the interests of moving forward, I think that Roger's 
> proposal is 
> > fine.
> > 
> > Cheers
> > James
> > 
> > 
> simplicity, and 
> > 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.
> > 
> > 
> > And yes, in Geopriv terms, a watcher asks a LS for the targets 
> > location, and gets the URI in response.
> > 
> > Brian
> > 
> > > > > > Cc: Winterbottom, James; 'Stark, Barbara'; 'Roger 
> Marshall'; 
> > > > > > [email-masked]
> > > > > > > The request is a parameter to HELD.  The return 
> could be a 
> > > > > > > parameter
> > > > > on
> > > > > > the
> > > > > > > URI itself, e.g.
> > > > > > >>> I don't think it quite satisfies. The "Location 
> Reference
> > > > > mechanism"
> > > > > > >>> protocol, plus whatever the server does to come 
> up with a
> > > > > reference,
> > > > > > >>>>       Motivation: Location references are not 
> intended to
> > > > > represent
> > > > > > >>>>
> > > > > > >> a
> > > > > > >>
> > > > > > >>>>       recycled, or may be subject to a 
> specific window of
> > > > > validity,
> > > > > > >>>>       after which the location reference fails 
> to yield a
> > > > > location,
> > > > > > >>>>
> > > > > > >> or
> > > > > > >>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Jul 2007 13:14:26 -0400

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:[email-masked]] 
Sent: Friday, July 27, 2007 12:42 PM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

James:

-roger marshall. 

*****

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

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 27 Jul 2007 10:28:12 -0700

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.

> Sent: Friday, July 27, 2007 10:14 AM
> To: Roger Marshall; Winterbottom, James; Brian Rosen; Hannes 
> Tschofenig
> Cc: [email-masked]
> 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
> 
> 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.
> 
> 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.
> 
> 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. 
> 
> 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.
> > 
> 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).
> > 
> > recycled,
> > determined to be kept confidential.  An expiry timer for a location 
> > reference ensures that the location reference becomes 
> invalid based on 
> > configuration.
> > 
> > 
> > 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.
> > 
> > > > > > > >> persons or entities other than the intended 
> recipient is
> > > > > > prohibited. If
> 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
> 
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 13:34:13 -0500

Hi Roger,

Certainly HELD has support for this with the context management draft.
I would add to Barbara's suggestion that the document have distinct
sections for each requirement set, so that responsibilities for each are
obvious.

Cheers
James

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Jul 2007 16:16:09 -0400

Since the ability to ask for a reference is in the basic HELD document,
I'd rather see the ability to set an expiration there, as well. The
return expiration is there already, too.
Barbara 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Friday, July 27, 2007 1:51 PM
To: Roger Marshall; Stark, Barbara; Brian Rosen; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

Hi Roger,

Cheers
James

> Sent: Saturday, 28 July 2007 3:28 AM
> To: Stark, Barbara; Winterbottom, James; Brian Rosen; Hannes
Tschofenig
> > > > > > > > >>>> Subject:
> > > > > > > > >>>> contain privileged, proprietary, or otherwise
private
> > > > > > > information.
> > > > > > > > >> this email is prohibited.
may
> > > > > > > and delete the original.  Any unauthorized use of
contain

*****

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. GA622

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 27 Jul 2007 15:54:57 -0500

Hi Barbara,

I can't see a good way of doing this without reintroducing the notion of
contexts back into the basic specification, since the time and other
policies relate specifically the set of URIs. 

One thing that we did get by moving context out as the ability for
people to support a very limited functionality LIS. Reintroducing
contexts (I don't care what we call them, the notion is the same) brings
quite a bit of that complexity back into the basic draft, and I am not
sure that the rest of the working group is ready to do that just yet.

Is there an issue with keeping this in a separate context management
draft?

Cheers
James

> Sent: Saturday, 28 July 2007 6:16 AM
> To: Winterbottom, James; Roger Marshall; Brian Rosen; Hannes
Tschofenig

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 29 Jul 2007 09:56:52 -0500

I definitely think that the target (rule maker) should have a mechanism
to cancel/invalidate a location reference. I asked for the reference to
begin with; if I subsequently think it may be used to my disadvantage
then I should have the ability to destroy it. I believe this is at least
part of the functionality of the context management draft.

If one accepts this capability, then any expiry that might be associated
with a transmitted reference is non-deterministic anyway; it may be
cancelled. So, any recipient of a location reference should be prepared
for a trial and error experience in any case.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 28 July 2007 1:24 AM
To: 'Roger Marshall'; Winterbottom, James; 'Hannes Tschofenig'
Cc: [email-masked]
Subject: RE: [Geopriv] RE: draft-marshall-geopriv-lbyr-requirements-01

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.

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

Brian

the
> line"), so there is only a URI.  Therefore, the expiry requirement
would
other
> > > > > I think we need a mechanism to define what the client
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-conte
> > > > > I'm not sure we need to convey the time.
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-http-location-
> > > > >> of uses) in the URI, for the case where I do want to send
that
components
> > > > >>> to be included in the URI itself, so that whoever gets the
URI
> > > > >>> message in error, please so notify the sender immediately,
and
or
contain