Subject: [Geopriv] Remove the HELD URI scheme?

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Jun 2008 17:00:08 -0400

Several comments on HELD (both from Ben's gen-art review and from EKR's 
secdir review) have resulted from the fact that while 
draft-ietf-geopriv-http-location-delivery-07 specifies the HELDS URI 
scheme, it doesn't adequately specify its use.  This is the motivation 
for including a normative reference to the HELD deref document, and the 
source of some security issues.  I wonder if some of these issues could 
be avoided by removing the definition of the URI scheme from this 
document and moving it to another document (e.g., deref or lis-discovery)

Recall that there was no HELD[S] URI scheme in the document until -04, 
when it was added in order to comply with RFC 3205's requirement that 
applications that use HTTP should use different port numbers, URI 
schemes, etc., under certain circumstances.
<http://www.ietf.org/mail-archive/web/geopriv/current/msg04602.html>
In particular, I think the introduction of the URI scheme in -04 was 
mainly due to a comment from Lisa:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg04645.html>
 > In general:
 >  - Fields that can contain arbitrary URLs are bad for interoperability
 >  - Fields that can contain HTTP URLs without clear expectations on
 >    what kind of resource must be at the URL, can also be bad for
 >    interoperability
 >  - These can both be bad for security and privacy

Now, I'd like to claim that we could remove the HELD URI scheme from the 
base HELD spec and still comply with that recommendation:
1. The URI scheme isn't necessary for the protocol to work. This 
document does not need to define a way to refer to HELD servers. That's 
the point of the LIS Discovery and HELD dereference documents.
2. The <locationURI> element should have constrains on its contents, but 
this could be done in the form of an IANA registry that lists URI 
schemes and referenced MIME types.  But this document would only need to 
create that document, not populate it.  (If an initial set of deref 
protocols is desired, we can fill in the SIP/SIPS/PRES mechanisms 
defined in draft-ietf-sip-location-conveyance.)

Is there a strong reason to keep the definition of the URI scheme in 
this document?

--Richard

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2008 14:22:18 -0700

At Fri, 20 Jun 2008 17:00:08 -0400,
> document and moving it to another document (e.g., deref or lis-discovery)

It's not clear to me that this solves the problem, or at least not all
of them.

I'm a device which wishes to get its own location. I use some
discovery (DHCP?) mechanism to get the URI which I dereference
using HELD? What is the content and semantics of that URI?

-Ekr

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 20 Jun 2008 16:28:28 -0500

I also don't think this proposal entirely solves all the problems,
although it minimizes the scope of issues. However, we are still using a
locationURI in the protocol, thus still need to scope its use and ensure
privacy, etc.  and we still need a URI to access the LIS.

What I was just thinking before I even read this email was that maybe we
should just remove the locationURI option for now. That would absolutely
remove all issues and then we can define it's use for HELD in a separate
document, which can define the schema and safely reference both the base
HELD document and the deref document. 

This leaves us with still needing to define a held:/helds: URI, but that
would only be used to access the LIS and could not be used to
dereference nor would it be carried in the locationResponse, where it
could potentially contain information related to the identity of the
requestor.  This point also relates to the discussion at the interim
about the potential need to make these URIs (LIS versus LbyR) distinct
anyways as I didn't like the fact that an initial request message for
location using HELD looks identical to a dereference request. But, I
think the real issue is that the URIs really are different.   Note, I've
brought Lisa back into  the discussion as this relates to my action item
to discuss with her whether or not we should be defining two distinct
types of URIs for these cases.

I know this proposal sounds rather silly, but I don't think we can
achieve the level of completeness/standalone-ness for HELD with the
locationURI as part of the base protocol, unless we can agree that we
will have a certain level of incompleteness until some of the other HELD
extensions are complete.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Rescorla
Sent: Friday, June 20, 2008 4:22 PM
To: Richard Barnes
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] Remove the HELD URI scheme?

Richard Barnes wrote:
> 
> Several comments on HELD (both from Ben's gen-art review and from 
> EKR's secdir review) have resulted from the fact that while

> for including a normative reference to the HELD deref document, and 
> the source of some security issues.  I wonder if some of these issues 
> could be avoided by removing the definition of the URI scheme from 
> this document and moving it to another document (e.g., deref or 
> lis-discovery)

I'm a device which wishes to get its own location. I use some discovery
(DHCP?) mechanism to get the URI which I dereference using HELD? What is
the content and semantics of that URI?

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Sun, 22 Jun 2008 20:41:07 -0400

Ekr,

There are three separate, functionally independenty things going on 
here, and three corresponding documents:
1. The HELD protocol, draft-ietf-geopriv-http-location-conveyance
2. HELD discovery, draft-ietf-geopriv-lis-discovery
3. HELD deref, draft-winterbottom-geopriv-deref-protocol

The first question is which of these documents should define a HELD URI 
scheme.  HELD URIs have been proposed for two purposes:
1. LIS Discovery: Pointing to a location configuration server.  When you 
send a dereference query to this URI, you get your own location.  These 
URIs are carried in HELD DHCP options in lis-discovery.
2. Location by reference: Pointing directly to a location object.  When 
you send a dereference query to this URI, you get a location chosen by 
the server.  These URIs are carried in HELD <locationURI> elements.

HELD can function without either of these things.  Much like you can use 
the DNS without using DHCP discovery, you can use HELD without HELD 
discovery.  And there are other location-by-reference protocols that can 
populate <locationURI> fields.  With that in mind, I was proposing that 
we move the definition of a HELD URI to either lis-discovery or deref, 
with the other of the two documents extending the definition with those 
semantics.

This doesn't resolve two questions:
1. How the locationURI field should be constrained, and
2. How a device can distinguish whether a HELD URI is a "discovery URI" 
or a "reference URI"
However, I think the first question can be addressed independently of 
the existence HELD URIs, and the second is beyond the scope of the base 
HELD specification.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Sun, 22 Jun 2008 20:45:13 -0400

I think that's throwing the baby out with the bath water.  Removing the 
locationURI element would prevent the use of existing LbyR schemes, such 
as those defined in draft-ietf-sip-location-conveyance.  I think that we 
can add text to appropriately constrain the contents of the field 
without defining a new URI scheme.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 22 Jun 2008 20:16:48 -0500

I totally agree Richard.
Further I believe that there is a need to be able to request location by
reference and value in the same location request, pushing location by
reference solely to HELD extensions will 1) not permit this to occur, 2)
will significantly delay support location URIs.

My position, to speed things along, is to define the held URI scheme in
the LIS discovery document, and describe its use for dereferencing in
the HELD dereference draft. I will point out that this stuff is not
rocket science, and like almost all other URI mechanisms how to use the
URI is context driven, both from the LIS and the URI holder's
perspective.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Richard Barnes
> Sent: Monday, 23 June 2008 10:45 AM
> To: Mary Barnes
> Cc: GEOPRIV
discovery
> > the content and semantics of that URI?

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

---

From: "TSG" <[email-masked]>
Date: Sun, 22 Jun 2008 19:04:41 -0800

you also need the when to complete this.

Todd Glassey

----- Original Message ----- 
From: "Winterbottom, James" <[email-masked]>
To: "Richard Barnes" <[email-masked]>; "Mary Barnes" 
<[email-masked]>
Cc: "GEOPRIV" <[email-masked]>
Sent: Sunday, June 22, 2008 5:16 PM
Subject: Re: [Geopriv] Remove the HELD URI scheme?

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 22 Jun 2008 21:37:18 -0500

I'm sorry Todd but I am missing your point, could you please clarify?

Cheers
James

> From: TSG [mailto:[email-masked]]
> Sent: Monday, 23 June 2008 1:05 PM
> To: Winterbottom, James; Richard Barnes; Mary Barnes
> Cc: GEOPRIV
> >> as those defined in draft-ietf-sip-location-conveyance.  I think
that
> > we
> >> > document, which can define the schema and safely reference both
the
> > base
> >> > This leaves us with still needing to define a held:/helds: URI,
but
> > that
> >> > dereference nor would it be carried in the locationResponse,
where
> > it
> >> > think the real issue is that the URIs really are different.
Note,
> > I've
> >> > brought Lisa back into  the discussion as this relates to my
action
> > item
> >> > locationURI as part of the base protocol, unless we can agree
that
> > we
> >> > will have a certain level of incompleteness until some of the
other
> > HELD
> >> > It's not clear to me that this solves the problem, or at least
not
> > all
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Jun 2008 22:49:58 -0500

We’ve already sorted out this problem:

> How a device can distinguish whether a HELD URI is a "discovery URI"
> or a "reference URI"

...is addressed in lis-discovery-01:

   The URI result from the discovery process is suitable for location
   configuration only; that is, the client MUST dereference the URI
   using the process described in HELD
   [I-D.ietf-geopriv-http-location-delivery].  URIs discovered in this
   way are not "location by reference" URIs; dereferencing one of them
   provides the location of the requester only.  Clients MUST NOT embed
   these URIs in fields in other protocols designed to carry the
   location of the client.

The other problem is uninteresting, but significant nonetheless.  I'm against IANA registries in general for such things, but it is one way to solve the problem.  The other way to solve the problem is to specify a MUST provide and allow for extras.  We have the MUST implement (HELD) already through other channels (ecrit-phone-bcp) and both HELD and SIP conveyance support multiple URIs.  The only thing missing is to say that you MUST provide a HELD URI.

Cheers,
Martin

> Behalf Of Richard Barnes
> Sent: Monday, 23 June 2008 10:41 AM
> To: Eric Rescorla
> Cc: 'GEOPRIV'
> EKR's

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Jun 2008 23:00:30 -0500

If I get a HELD URI from a discovery method, I mark that location URI has belonging to "me".  If I get it from SIP conveyance (or any other form of conveyance), I mark it as belonging to "that other thing", which depends on the semantics of the conveyance protocol, but it is probably the device or person at the other end of the dialog.

In short, each URI needs to have associated metadata that says "who".  Putting the "who" in the URI isn't safe, but recipients of the URI can do their own associations, and conveyance protocols need to have some way of communicating this belongedness.

Cheers,
Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Jun 2008 23:00:33 -0500

In all honesty, I can't see how putting this stuff in one draft or the other achieves anything at all.  If the objections exist for HELD, then the same objections apply no matter where the URI is documented.

On the other hand, I can still work without needing to understand everything.  I'd have no objection to taking the work up in lis-discovery.  There are a few changes that need to be made to that draft, clarifications and the like, so there's ample opportunity.  It would be good to come to some sort of conclusion so that this doesn't drag out.

Let's work out the objections and move on.

Ta,
Martin

> Behalf Of Winterbottom, James
> Sent: Monday, 23 June 2008 11:17 AM
> To: Richard Barnes; Mary Barnes
> Cc: GEOPRIV

<snip: read the archives>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 09:33:53 -0500

And, it's based on this point that I raised the concern at the interim
that currently HELD (or wherever we finally agree to define the URI
schema) uses the same URI scheme for both these things. Personally, it
would be clearer IMHO, given this point in some fashion was raised in
both gen-art and sec-dir reviews, to define two separate types of URIs,
particularly given that I believe the security around each is different.

I will that if no one else shares this concern, that's fine. But given
past experience with reviews by security ADs, I anticipate this being
raised again. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Sunday, June 22, 2008 10:50 PM
To: Richard Barnes
Cc: GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

The other problem is uninteresting, but significant nonetheless.  I'm
against IANA registries in general for such things, but it is one way to
solve the problem.  The other way to solve the problem is to specify a
MUST provide and allow for extras.  We have the MUST implement (HELD)
already through other channels (ecrit-phone-bcp) and both HELD and SIP
conveyance support multiple URIs.  The only thing missing is to say that
you MUST provide a HELD URI.

Cheers,
Martin

> 2. HELD discovery, draft-ietf-geopriv-lis-discovery 3. HELD deref, 
> draft-winterbottom-geopriv-deref-protocol
> 
> The first question is which of these documents should define a HELD 
> URI scheme.  HELD URIs have been proposed for two purposes:
> 1. LIS Discovery: Pointing to a location configuration server.  When 
> you send a dereference query to this URI, you get your own location.  
> These URIs are carried in HELD DHCP options in lis-discovery.
> 2. Location by reference: Pointing directly to a location object.  
> When you send a dereference query to this URI, you get a location 
> chosen by the server.  These URIs are carried in HELD <locationURI>
elements.
> 
> HELD can function without either of these things.  Much like you can 
> use the DNS without using DHCP discovery, you can use HELD without 
> HELD discovery.  And there are other location-by-reference protocols 
> that can populate <locationURI> fields.  With that in mind, I was 
> proposing that we move the definition of a HELD URI to either 
> lis-discovery or deref, with the other of the two documents extending 
> the definition with those semantics.
> 
> 1. How the locationURI field should be constrained, and 2. How a 
> device can distinguish whether a HELD URI is a "discovery URI"
> or a "reference URI"
> the existence HELD URIs, and the second is beyond the scope of the 
> base HELD specification.
> 
> --Richard
> 
> 
> 
> 
> Eric Rescorla wrote:
> >> draft-ietf-geopriv-http-location-delivery-07 specifies the HELDS 
> >> URI scheme, it doesn't adequately specify its use.  This is the
> motivation
> > discovery (DHCP?) mechanism to get the URI which I dereference using

> > HELD? What is the content and semantics of that URI?
> >
> > -Ekr
> >
> >
> 

------------------------------------------------------------------------
------------------------
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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 09:36:57 -0500

I don't disagree - that's why I suggested it was silly, and it's clear
that this approach wouldn't totally resolve the problem. However, I do
think we need to backup a bit and discuss whether it wouldn't help
clarify things if we define two separate URIs (one for LIS discover and
one for dereference), per my response to this thread (which isn't yet in
the archives):
http://www.ietf.org/mail-archive/web/geopriv/current/msg05744.html

Mary. 

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 7:45 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Eric Rescorla; GEOPRIV; Lisa Dusseault
Subject: Re: [Geopriv] Remove the HELD URI scheme?

--Richard

Mary Barnes wrote:
> although it minimizes the scope of issues. However, we are still using

> a locationURI in the protocol, thus still need to scope its use and 
> ensure privacy, etc.  and we still need a URI to access the LIS.
> 
> What I was just thinking before I even read this email was that maybe 
> we should just remove the locationURI option for now. That would 
> absolutely remove all issues and then we can define it's use for HELD 
> in a separate document, which can define the schema and safely 
> reference both the base HELD document and the deref document.
> 
> This leaves us with still needing to define a held:/helds: URI, but 
> that would only be used to access the LIS and could not be used to 

> brought Lisa back into  the discussion as this relates to my action 
> item to discuss with her whether or not we should be defining two 
> distinct types of URIs for these cases.
> 
> will have a certain level of incompleteness until some of the other 
> HELD extensions are complete.
> 
> Mary. 
> 
> 

> (DHCP?) mechanism to get the URI which I dereference using HELD? What 
> is the content and semantics of that URI?
> 
> -Ekr

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 09:39:56 -0500

I agree. Moving the definition just moves the problem.

I also don't think it at all helps to put this in LIS discovery as I
don't think it's appropriate to discuss dereferencing beyond the point
that it is already discussed. IMHO, what these threads are highlighting
is that for completeness HELD may need a normative reference to the
dereference document.  I don't see this as a huge concern, given that we
already have one to LIS discovery and that document is also behind HELD
in being progressed. 

The most important thing is we need the text to appropriately scope the
security around the URIs, with my opinion being its different for the
URI we get from LIS discovery than the one we use for dereference. 

Mary.  

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 11:01 PM
To: Winterbottom, James; Richard Barnes; Barnes, Mary (RICH2:AR00)
Cc: GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

In all honesty, I can't see how putting this stuff in one draft or the
other achieves anything at all.  If the objections exist for HELD, then
the same objections apply no matter where the URI is documented.

On the other hand, I can still work without needing to understand
everything.  I'd have no objection to taking the work up in
lis-discovery.  There are a few changes that need to be made to that
draft, clarifications and the like, so there's ample opportunity.  It
would be good to come to some sort of conclusion so that this doesn't
drag out.

Ta,
Martin

> Further I believe that there is a need to be able to request location 
> by reference and value in the same location request, pushing location 
> by reference solely to HELD extensions will 1) not permit this to 
> occur,
> 2)
> My position, to speed things along, is to define the held URI scheme 
> in the LIS discovery document, and describe its use for dereferencing 
> in the HELD dereference draft. I will point out that this stuff is not

> rocket science, and like almost all other URI mechanisms how to use 
> the URI is context driven, both from the LIS and the URI holder's 
> perspective.
> 
> Cheers
> James
> 
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 09:46:27 -0500

I agree with EKR here, per my responses to other recent threads. Moving
anything at this point just moves the problem to another document, which
would still be a normative reference for HELD.  However, per my
responses to other threads, at this point, I don't think we can get
around a normative reference to the dereference document.  We were
borderline on this issue during WGLC and I believe this sec-dir and
gen-art reviews suggest that we don't really have a way around it.  I
did propose rewording that would address Ben's concerns, however, I
don't know that the text will pass the security AD's review. 

I do agree that moving the definition will help the WG more quickly
progress HELD iff the sec-dir and gen-art reviewers agree that we've got
the right text around the usage, consistent with the necessary
references to the normative documents. So, we still need text. I do
wonder if it wouldn't help for me to go ahead an update the document
incorporating Ben's and EKR's points upon which we have agreement and
then attack the problem again. I realize this might take more time, but
I'm also anticipating difficulties in incorporating text that I've
agreed with Ben given this thread of discussion. 

Mary. 

-----Original Message-----

-Ekr

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jun 2008 10:53:09 -0400

How about a parameter (use=lcp or use=lbyr)?

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mary Barnes
> Sent: Monday, June 23, 2008 10:34 AM
> To: Thomson, Martin; Richard Barnes
> Cc: GEOPRIV

---

From: [email-masked]
Date: Mon, 23 Jun 2008 16:10:03 +0100

> How about a parameter (use=lcp or use=lbyr)?

Would that be a URI parameter or in the XML request?

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jun 2008 11:14:55 -0400

URI parameter: it indicates to anyone holding the URI what the URI can be
used for.

Brian
> Of [email-masked]
> Sent: Monday, June 23, 2008 11:10 AM
> To: [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jun 2008 08:42:42 -0700

At Sun, 22 Jun 2008 20:41:07 -0400,
> with the other of the two documents extending the definition with those 

I don't have a problem with that. But then this document cannot have
a normative dependency on that other dcocument unless it is substantially
finished.

> 2. How a device can distinguish whether a HELD URI is a "discovery URI" 

Well, there's a more basic question: how do you dereference a HELD
URI at all. The current document implies that you use HELD over HTTP,
but it doesn't actually say so.

Without directly addressing (2), it seems like a mistake to have
a URI which is intended to be dereferenced but does not contain sufficient 
information in and of itself to allow the URI holder to dereference.

-Ekr

---

From: "TSG" <[email-masked]>
Date: Mon, 23 Jun 2008 09:32:31 -0800

Sure James,

By the way - since we have formally told the IETF it doesnt own the IP under 
GeoPRIV that any communications regarding the vetting of IP's remain's our 
property.

As to the issue of sending IP to this list, NoteWell can only by its pure 
definition apply to IP's that the IETF is properly conveyed title to which 
in this case it was formally put on notice it doesnt OWN the IP under 
GEOPRIV. Michael McNeil and I own it - all of it based on our patent rights 
under US 6370629 and no rights in any form are conveyed to the IETF through 
this response posting either. If the IETF cannot tolerate that then it needs 
to shut down the GeoPRIV effort immediately.

That said - I am happy to answer your question.

---

In my mind the GeoSpatial Controls are at the very minimum based on either 
discrete control-event's or in range's of control events. I and McNeil 
designed our first pass at these in 1997 FWIW.

This control model is set by the policy atop the control process.  There are 
generally two primary classes of controls - one for location and one for 
time. Both are key to controlling commerce and Jurisdictional controls and 
can be combined with other telemetry system inputs or controls to effect 
data capture or systems control features based on location or time.

The system was initially also used to support a common Basic Event 
Representation Token (BERT) structure for representing Discrete instances or 
events in time and space. We submitted this to the IETF under the BERT 
program name and it was never published and since it was submitted before 
2026 was updated there was no conveyance of it either to the IETF.

    Location Controls
        Physical - i.e. street address, x:y location, lat:long or other NEMA 
or other tokens denoting a physical location, this would also pertain to 
auto-nav systems (and yes I have designed several including one called 
PaRTS - the Passive Roadway Telemetry System) just to name a few of the 
physical controls possible.  Likewise some other telemetry is possible here 
including temperature at location or at time for instance.

        Logical - i.e. Network Addresses in the form of TCP/IP or MAC 
address

        Virtual - i.e. EMail Addresses and the like (URI/URL's etc etc etc), 
based on the NDS translation of them to fixed or DHCP assigned Logical 
Adresses

    Time Controls
        Physical - i.e. TAI Seconds since last UTC Fixing by BIPM

        Logical - i.e. Complex Instances of time as a Range  of set of 
discrete time's

        Virtual - i.e. Complex Event's or Ranges of time pertaining to 
virtual policy controls - including global access control lists and the 
like.

These are all clearly covered in the patents.

Todd Glassey

----- Original Message ----- 
From: "Winterbottom, James" <[email-masked]>
To: "TSG" <[email-masked]>; "Richard Barnes" <[email-masked]>; 
"Mary Barnes" <[email-masked]>
Cc: "GEOPRIV" <[email-masked]>
Sent: Sunday, June 22, 2008 6:37 PM
Subject: RE: [Geopriv] Remove the HELD URI scheme?

Cheers
James

> > My position, to speed things along, is to define the held URI scheme
in
the
that
the
but
where
Note,
action
that
other
> > URI
not

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 23 Jun 2008 13:18:21 -0400

So, I looked at this patent. Please correct me if I'm wrong (reading
patent language isn't my strong suit), but it seems to be about a method
for authorizing access to stored information, based on the geodetic
location ("based on signals received at a receiver supplying reliable
position information" to me implies geodetic, especially when claim 2
says "said receiver comprises a GPS receiver") of the *stored*
information. Is this correct?

If so, I'm curious about which aspects of geopriv work you believe this
applies to. It's not clear to me, at all, since I'm not aware of any
geopriv efforts to provide authorization based on geo location. I'm
aware of geopriv statements around authorization by return routability,
and authorization by authentication -- but not authorization by geo
location. I am aware of statements (in LoST in ecrit) that provide
specific info based on location -- but no authorization is stated or
implied. Also, that information is provided based on the location
provided in the request, and not the location where the information is
stored. This patent very clearly states that it is about authorization
to access stored information, based on the location of the stored
information.

I think it would be helpful if you could point to the geopriv work
effort that you believe is impinging on this patent. Because I'm not
seeing it. If you really meant some other patent number, it would be
good to know that number. Thanks,
Barbara 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of TSG
Sent: Monday, June 23, 2008 1:33 PM
To: Winterbottom, James; Richard Barnes; Mary Barnes
Cc: GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

Sure James,

By the way - since we have formally told the IETF it doesnt own the IP
under 
GeoPRIV that any communications regarding the vetting of IP's remain's
our 
property.

As to the issue of sending IP to this list, NoteWell can only by its
pure 
definition apply to IP's that the IETF is properly conveyed title to
which 
in this case it was formally put on notice it doesnt OWN the IP under 
GEOPRIV. Michael McNeil and I own it - all of it based on our patent
rights 
under US 6370629 and no rights in any form are conveyed to the IETF
through 
this response posting either. If the IETF cannot tolerate that then it
needs 
to shut down the GeoPRIV effort immediately.

---

In my mind the GeoSpatial Controls are at the very minimum based on
either 
discrete control-event's or in range's of control events. I and McNeil 
designed our first pass at these in 1997 FWIW.

This control model is set by the policy atop the control process.  There
are 
generally two primary classes of controls - one for location and one for

time. Both are key to controlling commerce and Jurisdictional controls
and 
can be combined with other telemetry system inputs or controls to effect

The system was initially also used to support a common Basic Event 
Representation Token (BERT) structure for representing Discrete
instances or 
events in time and space. We submitted this to the IETF under the BERT 
program name and it was never published and since it was submitted
before 
2026 was updated there was no conveyance of it either to the IETF.

    Location Controls
        Physical - i.e. street address, x:y location, lat:long or other
NEMA 
or other tokens denoting a physical location, this would also pertain to

auto-nav systems (and yes I have designed several including one called 
PaRTS - the Passive Roadway Telemetry System) just to name a few of the 
physical controls possible.  Likewise some other telemetry is possible
here 
including temperature at location or at time for instance.

        Virtual - i.e. EMail Addresses and the like (URI/URL's etc etc
etc), 
based on the NDS translation of them to fixed or DHCP assigned Logical 
Adresses

    Time Controls

Todd Glassey

----- Original Message ----- 
From: "Winterbottom, James" <[email-masked]>
To: "TSG" <[email-masked]>; "Richard Barnes" <[email-masked]>; 

Cheers
James

in
the
that
the
but
where
Note,
action
that
other
not

*****

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: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Jun 2008 13:25:57 -0400

Also looks like all claims require encryption.  While we may get encryption
via TLS, I don't think we meet the use as described in the patent.

Brian

> Of Stark, Barbara
> Sent: Monday, June 23, 2008 1:18 PM
> To: TSG; Winterbottom, James; Richard Barnes; Mary Barnes
> Cc: 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. GA622
> 
>

---

From: "TSG" <[email-masked]>
Date: Mon, 23 Jun 2008 10:32:07 -0800

Barbara
The stored information can be any object - read claims 26 through 32. The 
authorization is the 'access control' which is used to select which stored 
entity is accessed.

Michael - chime in here if you would too!

Todd

----- Original Message ----- 
From: "Stark, Barbara" <[email-masked]>
To: "TSG" <[email-masked]>; "Winterbottom, James" 
<[email-masked]>; "Richard Barnes" <[email-masked]>; "Mary 
Barnes" <[email-masked]>
Cc: "GEOPRIV" <[email-masked]>
Sent: Monday, June 23, 2008 9:18 AM
Subject: RE: [Geopriv] Remove the HELD URI scheme?

-----Original Message-----

Sure James,

---

    Location Controls

    Time Controls

Todd Glassey

----- Original Message ----- 
From: "Winterbottom, James" <[email-masked]>
To: "TSG" <[email-masked]>; "Richard Barnes" <[email-masked]>;

Cheers
James

in
the
that
the
but
where
Note,
action
that
other
not

*****

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: "TSG" <[email-masked]>
Date: Mon, 23 Jun 2008 10:34:58 -0800

Hashing or reducing from some 'ASCII to binary form' also works - so does 
'encoding' in any other language. This has been well documented in the 
Court's. Likewise using any number of other encoding forms is also covered. 
So Crypto is only part of the bigger picture.

This has already been tested once in Court. But hey - I am assuming that it 
will take getting people's General Counsel's into this mix to sort it out.

Todd
----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Stark, Barbara'" <[email-masked]>; "'TSG'" <[email-masked]>; 
"'Winterbottom, James'" <[email-masked]>; "'Richard Barnes'" 
<[email-masked]>; "'Mary Barnes'" <[email-masked]>
Cc: "'GEOPRIV'" <[email-masked]>
Sent: Monday, June 23, 2008 9:25 AM
Subject: RE: [Geopriv] Remove the HELD URI scheme?

---

From: "TSG" <[email-masked]>
Date: Mon, 23 Jun 2008 10:38:23 -0800

By the way Brian - NTP went through the same stuff we are now having to 
trudge through here with this IP, but hey, its OK - they got 250M+ for that 
IP, and this patent is probably worth 50 to 100 times that based on its 
size.

Hell it controls GPS Receiver's selecting a digital image from their local 
storage and displaying it on their local display's among other things.

Todd Glassey

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jun 2008 17:57:37 -0400

I assume that it would then have to be mandatory.  Otherwise, what would 
the interpretation of a "bare" URI?
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jun 2008 18:02:30 -0400

Mary,

I'm willing to go with your suggestion to rev the document with Ben and 
Ekr's comments, then take a second look at it.  Would it be worthwhile 
to go ahead and include Brian's suggested "use=" tag?  The usage defined 
in this document would be the "lcp" case; other document could define 
different usages.

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jun 2008 18:14:09 -0500

I have to ask why we need this use= thing?

This problem is exactly the same as the case that I have a sip URI, can
I send the proxy a register, a subscribe, etc. Basically, to what does
the URI apply? As with the SIP case, the use of the URI is contextual,
and the proxy needs to have some understanding as to what the context is
also.

I am having a great deal of trouble actually understanding what the real
issues are. The only real issue I am hearing is what happens in the case
where a held URI is included in a returned locationURI set. What I don't
understand is why this is even a problem. All the specification needs to
say is that only URIs that have specifications defining a dereference
function may be used. Don't talk about HELD deref in this document at
all, leave that for the HELD dereference document. How the LIS knows
what to do with the URI is an implementation detail, and I can think of
several ways this can easily be done, and have implemented at least one
in the Open Source LIS.

I am strongly opposed to including a use= attribute in the HELD schema.

Cheers
James

Behalf
> Of Richard Barnes
> Sent: Tuesday, 24 June 2008 8:03 AM
> To: Mary Barnes
> Cc: GEOPRIV
URI
discovery

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 23 Jun 2008 18:32:05 -0500

I don't think that the URI parameter is necessary, as I pointed out already [1].  That doesn't stop there from being text that makes it clear what can be used and when and how.  That text needs to go with the definition of the URI, wherever that might be.

That said, a URI parameter doesn't hurt.  A location URI that comes from discovery can be used differently to other location URIs.  That could be recorded rather than indicated through a parameter.

I agree with Richard on the revision.  A revision can address most of the gen-art and sec-dir comments now.  As long as we understand what the remaining issues are, working from a revision will help.

~M

[1] http://www.ietf.org/mail-archive/web/geopriv/current/msg05745.html

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 18:48:47 -0500

There are two reasons why we can't just ignore the concept of a location
dereference in the based HELD document (that was my silly suggestion
over the weekend):
1. We need to appropriately describe the parameter that is returned from
the LIS and it needs to have some minimal security statements as to its
potentially revealing identity, issues with IP address spoofing, etc.
2. Even if we could agree 1 was not necessary, we cannot get rid of the
reference (at least informational) to the deref document IF we leave the
schema in this document. As I understand the template for new schemas,
you must identify the protocols that are allowed to use that schema. The
deref protocol is one of those protocols. 
3. I also don't think this helps with needing the clarify the use of the
held: URI for LIS discovery in the current HELD document. IMHO, it makes
sense for that to be in the LIS discovery document (it's already partly
or perhaps even mostly there). That allows the schema and the minting of
the URI to be in one place, which clarifies the HELD document. 

I fully agree that from an implementation perspective it doesn't matter
what type of URI we're using.  I don't think anyone is debating whether
what we currently have specified could be made to work. The issue is
IMHO that we're overloading the held: URI because it can represent two
different things: 1. a reference to a LIS   2. a reference to a location
for a specific user.  Given that they reference different things, I
would think the security requirements should be different.   I also
think it will be slightly easier to debug if the URIs are of different
schemas -i.e., it's totally obvious from looking at a trace whether
you're doing an initial location request or dereferencing a URI. I agree
that both return the same thing and there may be a slick way to
implement these to optimize LIS processing, but I think it makes the
security of the protocol more difficult to scope and clarify.

Personally, I would like feedback on this proposal as I think it's the
clearest way forward:
 http://www.ietf.org/mail-archive/web/geopriv/current/msg05758.html

I've only gotten one response from Hannes so far and he's neutral.

Mary. 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 6:14 PM
To: Richard Barnes; Barnes, Mary (RICH2:AR00)
Cc: GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

Cheers
James

Behalf

URI

discovery

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jun 2008 19:51:32 -0400

James,

The issue is that there can be ambiguity in HELD requests.  To compare 
to SIP, when I send a SIP SUBSCRIBE:

SUBSCRIBE <sip:[email-masked]> SIP/2.0
...headers...
...body...

... it means that what I get back corresponds to <sip:[email-masked]>, no 
matter who I am.  I could pass the URI <sip:[email-masked]> to someone in 
Australia, and they would still get the same information (up to privacy 
transforms, of course!).

On the other hand, if I get a random HELD URI from somewhere and make a 
query to it ...

POST held://lis.example.net:8080/lis/ HTTP/1.1
...headers...
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
   <locationType exact="true">
     geodetic
     civic
   </locationType>
</locationRequest>

... then I, as a client, have no way to know whether I'm getting back my 
own location, or the location of some third entity.  And I can't be sure 
that if I send it to my friend in another hemisphere, that he'll get 
equivalent results (since it might be an LCP URI).

As Martin has noted, there's no obvious harm in creating a usage flag, 
and it clears up this ambiguity.

--Richard

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 19:17:28 -0500

My primary concern about a revision at this point is that half of Ben's
and almost all of Ekr's comments center around the issues we're
currently debating. It's at least a solid 8 hours of editting to
carefully address all those comments and depending upon what we agree to
do here, a lot of that text that I change might be deleted and/or
changed again. 

So, again, I'd like to ask the group to provide feedback on the
following proposal:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05758.html

If there's not a majority in support of this approach, then I'll make
the revision and we can continue the debate. But, again, given that we
debated this same topic during our first WGLC (remember we've already
been through 2 WGLCs on this document and these comments are IETF LC
ones) without complete consensus (we removed the reference to the deref
document in the description of the locationURI parameter (-04 to -05
change), but left it in the schema section). So, I really think we're
headed for more problems down the line if we try to keep the URI schema
in the base HELD document. Per EKR's comment below, the issues around
dereferencing should be independent of HELD. 

Mary. 

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 6:32 PM
To: Richard Barnes; Barnes, Mary (RICH2:AR00)
Cc: GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

I don't think that the URI parameter is necessary, as I pointed out
already [1].  That doesn't stop there from being text that makes it
clear what can be used and when and how.  That text needs to go with the
definition of the URI, wherever that might be.

That said, a URI parameter doesn't hurt.  A location URI that comes from
discovery can be used differently to other location URIs.  That could be
recorded rather than indicated through a parameter.

I agree with Richard on the revision.  A revision can address most of
the gen-art and sec-dir comments now.  As long as we understand what the
remaining issues are, working from a revision will help.

~M

> I'm willing to go with your suggestion to rev the document with Ben 
> and Ekr's comments, then take a second look at it.  Would it be 
> worthwhile to go ahead and include Brian's suggested "use=" tag?  The 
> usage defined in this document would be the "lcp" case; other document

> could define different usages.
> 
> --Richard
> 
> 
> 
> Mary Barnes wrote:
> > gen-art reviews suggest that we don't really have a way around it.  
> > I did propose rewording that would address Ben's concerns, however, 
> > I don't know that the text will pass the security AD's review.
> >

> > incorporating Ben's and EKR's points upon which we have agreement 
> > and then attack the problem again. I realize this might take more 
> > time,
> but

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jun 2008 22:24:54 -0500

Hi Mary,

Here is my view, which kind of lines up with some of what you said.

1) Move the definition of the HELD URI scheme to the LIS discovery
document.
2) Don't talk about HELD dereference in the basic HELD specification at
all
3) In the HELD dereference document add the use=deref element to the URI
defined in 2) if that is the way we choose to address the difference in
usage.

Cheers
James

Behalf
> Of Mary Barnes
> Sent: Tuesday, 24 June 2008 10:17 AM
> > > progress HELD iff the sec-dir and gen-art reviewers agree that
we've
> > got

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jun 2008 07:41:27 -0400

Your approach seems fine to me.  I am neutral on whether two schemes or one
scheme and a parameter distinguishes the two different uses for a URI.

Brian

> Sent: Monday, June 23, 2008 8:17 PM

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Jun 2008 08:24:12 -0400

James,

Suggest a slight change to that plan:  With respect to (1), ISTM that 
the base HELD document (http-location-delivery) needs to define what the 
URI looks like that goes in a HELD request, namely it needs to define 
the "LCP URI" format.  I think that that implies that for (3), the base 
document also needs to define the use flag so that LCP URIs can be 
flagged "use=lcp".

To summarize:
1) In http-location-conveyance, define the HELD URI scheme for referring 
to a LIS (the LCP usage), including the use flag with the single value 
"lcp".
2) Don't talk about HELD dereference in the basic HELD specification at all
3) In held-deref, define the usage of HELD URIs for lbyr, and the 
"deref" value for the use flag.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Jun 2008 09:52:59 -0400

However, if you say in the base spec that "This is what the Request URI 
is going to look like", and then you add the use flag later, then that 
document will have to update the base spec, and implementations of the 
base spec will have to change to accommodate the flag.  Seems easier on 
implementers just to go ahead and add the flag (since we know it will be 
necessary).

--Richard

Winterbottom, James wrote:
> Hi Richard,
> 
> I guess my rationale for not putting the flag into the base specification is that the flag only becomes an issue when the URI can have more than one meaning. If the base specification doesn't talk about deref, then the URI only has one meaning, so the use flag looks odd.
> 
> Cheers
> James
> 
> 
> Sent: Tue 6/24/2008 7:24 AM
> To: Winterbottom, James
> Cc: Mary Barnes; Thomson, Martin; GEOPRIV

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jun 2008 08:59:21 -0500

Not really.
The base spec (or the LIS discovery document) defines what the URI looks like for LCP. The format already allows for additional attributes on the URI line, it just doesn't specify what they are.
The deref spec says, hey HELD can be used as a dereference protocol too, LIS if you want to provide HELD URIs for dereference you can, but you must include this new parameter on the end of the URI to indicate that it is a dereference URI.

I don't see how this needs to alter the base specification.

Cheers
James

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Tue 6/24/2008 8:52 AM
To: Winterbottom, James
Cc: Mary Barnes; Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jun 2008 08:43:08 -0500

Hi Richard,

Cheers
James

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Tue 6/24/2008 7:24 AM
To: Winterbottom, James
Cc: Mary Barnes; Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?
 
James,

To summarize:

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Jun 2008 10:45:13 -0400

So what you're proposing is that an "unadorned" URI would be an LCP URI, 
by default, and a URI with use=deref is a deref URI (in effect, removing 
use=lcp).  The alternative being that use= is mandatory, and "unadorned" 
URIs are not defined.

I'm a little bit of two minds on this: I like having a default 
interpretation, since it avoids the complexity of handling the 
"unadorned" case separately.  On the other hand, given that URI 
parameters aren't all that frequently used today, I'm concerned about 
parameters getting dropped and changing the semantic.

Given those concerns, I think the lower-risk path is to require the use 
parameter, and just declare unadorned URIs syntactically invalid (this 
is equivalent to having two schemes).

In any case, I think that the URI scheme has to go in the base document 
(I realize I'm flip-flopping here), so that the client and server know 
what the Request-URI MUST look like.

--Richard

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 24 Jun 2008 11:13:19 -0500

Just a few comments below [MB].  Note also that I just forwarded Ben's
gen-art review comments, which did not get to GEOPRIV WG mailing list.

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 9:45 AM
To: Winterbottom, James
Cc: Barnes, Mary (RICH2:AR00); Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

URIs are not defined.

[MB] Actually, SIP uses URI parameters, so I wouldn't consider that
infrequent. [/MB]

Given those concerns, I think the lower-risk path is to require the use
parameter, and just declare unadorned URIs syntactically invalid (this
is equivalent to having two schemes).
[MB] My preference is to be really explicit and define two different
schemas. [/MB]

In any case, I think that the URI scheme has to go in the base document
(I realize I'm flip-flopping here), so that the client and server know
what the Request-URI MUST look like.
[MB] I think the URI schema, which is the output from the LIS discovery
should be in that document. I think the URI schema for the dererencing
should be in that document. Yes, we MUST define the characteristics of
the locationURI in the protocol, BUT that URI can actually be any URI
because it's not mandatory that the LIS discovery produces a held: URI
nor does the URI to be dereferenced have to be a held:URI and it is not
mandatory that the dereferencing protocol be based on HELD. That might
be our default one, but may not be the only one - per my response to
Ben's concerns, which I've just now realized did not make it to the
mailing list. I will forward all of those that did not make it. [/MB]

--Richard

Winterbottom, James wrote:
> Not really.
> The base spec (or the LIS discovery document) defines what the URI
looks like for LCP. The format already allows for additional attributes
on the URI line, it just doesn't specify what they are.
> The deref spec says, hey HELD can be used as a dereference protocol
too, LIS if you want to provide HELD URIs for dereference you can, but
you must include this new parameter on the end of the URI to indicate
that it is a dereference URI.
> However, if you say in the base spec that "This is what the Request 
> URI is going to look like", and then you add the use flag later, then 
> that document will have to update the base spec, and implementations 
> of the base spec will have to change to accommodate the flag.  Seems 
> easier on implementers just to go ahead and add the flag (since we 
> know it will be necessary).
> 
> --Richard
> 
> 
> 
>> I guess my rationale for not putting the flag into the base
specification is that the flag only becomes an issue when the URI can
have more than one meaning. If the base specification doesn't talk about
deref, then the URI only has one meaning, so the use flag looks odd.

>> the base HELD document (http-location-delivery) needs to define what 
>> the URI looks like that goes in a HELD request, namely it needs to 
>> define the "LCP URI" format.  I think that that implies that for (3),

>> the base document also needs to define the use flag so that LCP URIs 
>> can be flagged "use=lcp".
>>
>> To summarize:
>> 1) In http-location-conveyance, define the HELD URI scheme for 
>> referring to a LIS (the LCP usage), including the use flag with the 
>> single value "lcp".
>>> 2) Don't talk about HELD dereference in the basic HELD specification

>>> at all
>>> 3) In the HELD dereference document add the use=deref element to the

>>> URI defined in 2) if that is the way we choose to address the 
>>> difference in usage.
>>>
>>>
>>> Cheers
>>> James
>>>
>>>
>>>> carefully address all those comments and depending upon what we 
>>>> agree
>>> to
>>>> If there's not a majority in support of this approach, then I'll 
>>>> make the revision and we can continue the debate. But, again, given

>>>> that we debated this same topic during our first WGLC (remember 
>>>> we've already been through 2 WGLCs on this document and these 
>>>> comments are IETF LC
>>>> document in the description of the locationURI parameter (-04 to 
>>>> -05 change), but left it in the schema section). So, I really think

>>>> we're headed for more problems down the line if we try to keep the 
>>>> URI
>>> schema
>>>> in the base HELD document. Per EKR's comment below, the issues 
>>>> around dereferencing should be independent of HELD.
>>>>
>>>> Mary.
>>>>

>>>> clear what can be used and when and how.  That text needs to go 
>>>> with
>>> the
>>>> discovery can be used differently to other location URIs.  That 
>>>> could
>>> be
>>>> I agree with Richard on the revision.  A revision can address most 
>>>> of the gen-art and sec-dir comments now.  As long as we understand 
>>>> what
>>> the
>>>> [1] 
>>>> http://www.ietf.org/mail-archive/web/geopriv/current/msg05745.html
>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>> On Behalf Of Richard Barnes
>>>>> I'm willing to go with your suggestion to rev the document with 
>>>>> Ben and Ekr's comments, then take a second look at it.  Would it 
>>>>> be worthwhile to go ahead and include Brian's suggested "use="
tag?
>>> The
>>>>>> anything at this point just moves the problem to another 
>>>>>> document,
>>>>> which
>>>>>> around a normative reference to the dereference document.  We 
>>>>>> were borderline on this issue during WGLC and I believe this 
>>>>>> sec-dir
>>> and

>>>>>> time,
>>>>> but
>>>>>> I'm also anticipating difficulties in incorporating text that 
>>>>>> I've agreed with Ben given this thread of discussion.
>>>>>>
>>>>>> Mary.
>>>>>>
>>>>>> At Fri, 20 Jun 2008 17:00:08 -0400, Richard Barnes wrote:
>>>>>>> Several comments on HELD (both from Ben's gen-art review and 
>>>>>>> from EKR's secdir review) have resulted from the fact that while

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jun 2008 17:13:10 -0500

Hi Mary,

I have several points to make on your comments below.
HELD, as defined now, describes an LCP, so there is no need to say this URI defines an LCP scheme, it is more than implied. I remain totally unconvinced that a new URI scheme is required for dereference, however I don't think my being convinced or not has any bearing on what we put in the base-HELD spec at this time, since the use of a parameter or a new URI scheme is a debate for the deref draft.

Secondly LIS discovery is written such that it finds you a HELD server, if we define a HELD URI for LCP purposes, then LIS discovery does mandate that the URI returned in a HELD URI.

Cheers
James

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tue 6/24/2008 11:13 AM
To: Richard Barnes; Winterbottom, James
Cc: Thomson, Martin; GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 9:45 AM
To: Winterbottom, James
Cc: Barnes, Mary (RICH2:AR00); Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

URIs are not defined.

--Richard

tag?

>>> On

>>> ----
>>> ----

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

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

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 24 Jun 2008 17:51:36 -0500

A few comments below [MB].

Mary.

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 5:13 PM
To: Barnes, Mary (RICH2:AR00); Richard Barnes
Cc: Thomson, Martin; GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

Hi Mary,

I have several points to make on your comments below.
HELD, as defined now, describes an LCP, so there is no need to say this
URI defines an LCP scheme, it is more than implied. I remain totally
unconvinced that a new URI scheme is required for dereference, however I
don't think my being convinced or not has any bearing on what we put in
the base-HELD spec at this time, since the use of a parameter or a new
URI scheme is a debate for the deref draft.
[MB] Yes, we know that you're unconvinced of the need for a new URI
schema. However, clarity is required for the base-HELD spec since we
MUST describe the locationURI parameter and usages and security required
accurately. As well, I will highlight for about the 10th time that the
confusion between the two usages of the URIs was brought up in both the
gen-art and sec-dir reviews. I certainly didn't clearly see the source
of confusion until we were at the interim and I realized through your
examples that someone looking at a trace would not be able to determine
if you were doing a location request or were dereferencing a location.
And, the reason why I didn't see this before was because I was too
familiar with the document and it was totally obvious to me that we were
using the same URI schema for two different usages (as it is to most on
the WG mailing list right now I would imagine).   Please correct me if
I'm wrong, but does the LIS not have to function slightly differently in
these two cases?  And, yes, I do realize that with clever coding, you
can easily figure this out, but my concern is someone looking at the
messages on the wire.  

Also, as editor, I have concerns over supporting the current single URI
schema approach given that both gen-art and sec-dir reviewers raised
issues around this.   The text I provided to Ben in my response was
adequate, but given that Ekr also has concerns, we should really pay
attention and reconsider the current approach.  Based on past
experience, we will have a hard enough time with text that is absolutely
obvious to everyone in this WG, but could well be missing key concepts
(again the familiarity issue). 
IMHO, if we're having these concerns raised during IETF LC, we would do
well to consider them. And, yes, we can add text to clarify things with
a single URI schema, however, I would not be surprised at all to thus
have this same discussion post IESG review. [/MB]

Secondly LIS discovery is written such that it finds you a HELD server,
if we define a HELD URI for LCP purposes, then LIS discovery does
mandate that the URI returned in a HELD URI.
[MB] Right now, LIS discovery does not mandate that it be a held: URI.
Martin, is that a change that's planned?  Also, if that's the case, then
that's even more of a reason to define the schema in LIS discovery,
since we'd end up with normative circular references between HELD and
LIS discovery documents (not that it's not been done before, but really
this highlights a scope issue IMHO).

Cheers
James

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tue 6/24/2008 11:13 AM
To: Richard Barnes; Winterbottom, James
Cc: Thomson, Martin; GEOPRIV
Subject: RE: [Geopriv] Remove the HELD URI scheme?

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, June 24, 2008 9:45 AM
To: Winterbottom, James
Cc: Barnes, Mary (RICH2:AR00); Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Remove the HELD URI scheme?

URIs are not defined.

--Richard

tag?

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 23:17:55 -0500

> using HELD? What is the content and semantics of that URI?

I haven't read the spec today, so let me guess -- and if the truth is  
something different, then the protocol is crazy.

Here's my guess:

It's just an HTTP URL (why they called it something else is beyond me,  
and arguably one of the less rational decisions I know about) to which  
you connect using HTTP, do a GET on, and either get an auth challenge  
or a PIDF/LO MIME object.

You could do this with wget if it weren't for the URL type not being  
recognized (which requires rewriting truckloads of software just to  
use the nonstandard naming scheme).

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 23:27:09 -0500

On Jun 24, 2008, at 11:17 PM, Dean Willis wrote:

>>
>
> I haven't read the spec today, so let me guess -- and if the truth  
> is something different, then the protocol is crazy.
>
> Here's my guess:
>
> It's just an HTTP URL (why they called it something else is beyond  
> me, and arguably one of the less rational decisions I know about) to  
> which you connect using HTTP, do a GET on, and either get an auth  
> challenge or a PIDF/LO MIME object.
>

And yes, for those of you who are already beating me up, I'm being  
facetious. You people are quick!

But I really do think we hideously overdesigned this beasty.

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 25 Jun 2008 08:57:28 -0500

I don't think the protocol is over-designed, although, many of the
recent threads of discussion make it appear so. IMHO, we've had a lot of
crosstalk - repeating the same things using different words, over and
over.  I will post something shortly that I believe summarize the key
issues and a proposed way forward.

However, you point is well taken - we really need to make sure we don't
add unnecessary complication or confusion to the protocol. Both the
gen-art and sec-dir reviews have clearly highlighted that some of our
compromise text is insufficient and confusing.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Tuesday, June 24, 2008 11:27 PM
To: Dean Willis
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] Remove the HELD URI scheme?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Jun 2008 08:01:45 -0700

At Tue, 24 Jun 2008 23:17:55 -0500,
> or a PIDF/LO MIME object.

Actually, it looks to me like you do a POST, per S 9 of 
draft-ietf-geopriv-http-location-delivery-07. But I have
to admit I'm not sure because the section that describes
the URI doesn't actually say as far as I can tell.

-Ekr