Subject: Re: [Geopriv] Round 2: Editor's proposal: resolving held: URI concerns

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Jul 2008 09:45:45 -0700

I apologize for not replying to this directly. I've been swamped.

Anyway, I don't think this really works out very well, for reasons
I indicated in the review I just posted.

At Thu, 26 Jun 2008 10:32:10 -0400,
Richard Barnes wrote:
> 
> Mary,
> 
> That plan looks good to me.
> 
> --Richard
> 
> 
> 
> Mary Barnes wrote:
> > I'm going to give this another shot as based on a chat yesterday with 
> > James W., I think there's been alot of crosstalk. And I'm happy to see 
> > that seems to have stopped for now.
> >  
> > There were two neutral responses to this proposal and then I believe 
> > just 4 of us debating things in circles.  
> >  
> > Based on gen-art and sec-dir feedback, there were concerns raised about 
> > the two URIs: URI from LIS Discovery and URI in the locationURI field in 
> > a locationResponse message.
> > I think it's really important to note that these reviews were entirely 
> > independent since I realized yesterday that gen-art comments had not 
> > gone to the WG mailing list.
> >  
> >  In terms of the content of the document, the concerns raised relate 
> > primarily to the following sections:
> > - 4.2 Overview of Location by Reference
> > - 6.5 (.1) Definition of locationURI parameter  (where we had previously 
> > had WG discussion and a reference to the dereference document (removed 
> > as a result of 1st WGLC))
> > - 8: HELDS: URI definition.   Here is where we define the two uses of 
> > the URI. 
> >  
> > In order to resolve these concerns, I'm proposing the following changes:
> >  
> > 1) Differentiate the two URIs by either of the following:
> > 1a) Define two sets of schemas (recalling the past agreement that we 
> > needed to define both held:/helds:)
> > 1b) Add a parameter to the URI schema.  
> >  
> > Note: I do not believe we have the option of deferring this distinction 
> > in terms of only defining a tag/parm for dereference because the 
> > ambiguity exists in the base-HELD document and unless we remove the 
> > location by reference altogether (my past silly suggestion), we must 
> > resolve the ambiguity in base-HELD.
> >  
> > My preference is for 1a, as I think it makes the distinction clearer.

This seems fine.

> > I 
> > believe the URI schema returned from LIS Discovery should go in that 
> > document. That makes base-HELD entirely neutral on the form of the LIS 
> > Discovery URI (as it currently is).  I think it's entirely appropriate 
> > for the URI schema for the location by reference to go in base-HELD.  
> > So, overall, this change does not have a huge impact on base-HELD other 
> > than clarifying the text as appropriate in the above sections.

Actually, I don't think this works out very well. 

What HELD really specifies now is how a user gets their location from
an LIS. It's odd to have the URI for *that* in another document.

What it doesn't specify (and doesn't even normatively reference) is how
location by reference works. It's odd to have that in this document.

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

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 15 Jul 2008 13:30:14 -0500

Ekr,

I'm not clear at all what comment in your other response implies this
doesn't work very well. Are you concerned because the text below doesn't
mention a reference to the HELD-dereference document? In that case, that
shouldn't be a concern as the dependency has been added back in.
Although right now I have it as informational because this document does
not provide in any way the ability to dereference that URI. However, we
need to define the form of that URI (in this document) in order to
provide the appropriate details on the parameter. Thus the WG chose to
define the URI schema in this document.

And, I've a couple aditional comments and questions for clarification
embedded below.

Thanks,
Mary. 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 11:46 AM
To: Richard Barnes
Cc: Barnes, Mary (RICH2:AR00); GEOPRIV
Subject: Re: [Geopriv] Round 2: Editor's proposal: resolving held: URI
concerns

Anyway, I don't think this really works out very well, for reasons I
indicated in the review I just posted.

Richard Barnes wrote:
> > I'm going to give this another shot as based on a chat yesterday 
> > with James W., I think there's been alot of crosstalk. And I'm happy

> > to see that seems to have stopped for now.
> >  

> > Based on gen-art and sec-dir feedback, there were concerns raised 
> > about the two URIs: URI from LIS Discovery and URI in the 
> > locationURI field in a locationResponse message.
> > I think it's really important to note that these reviews were 
> > entirely independent since I realized yesterday that gen-art 
> > comments had not gone to the WG mailing list.
> >  

> > - 6.5 (.1) Definition of locationURI parameter  (where we had 
> > previously had WG discussion and a reference to the dereference 
> > document (removed as a result of 1st WGLC))

> > Note: I do not believe we have the option of deferring this 
> > distinction in terms of only defining a tag/parm for dereference 
> > because the ambiguity exists in the base-HELD document and unless we

> > remove the location by reference altogether (my past silly 
> > suggestion), we must resolve the ambiguity in base-HELD.
> >  

This seems fine.

> > document. That makes base-HELD entirely neutral on the form of the 
> > LIS Discovery URI (as it currently is).  I think it's entirely 
> > appropriate for the URI schema for the location by reference to go
in base-HELD.
> > So, overall, this change does not have a huge impact on base-HELD 
> > other than clarifying the text as appropriate in the above sections.

What HELD really specifies now is how a user gets their location from an
LIS. It's odd to have the URI for *that* in another document.
[MB] Just to clarify the URI schema that we moved into LIS discovery is
the URI that is the target for the locationRequest. Also, note that
there are some errors in the current examples, as highlighted by Martin
T:

Are you concerned because we haven't described the dereferencing
functionality in this document?  If so, this is contrary to how the WG
has split and chartered the work.  IMHO, the best we can do is mention
that the locationURI is meaningless without the implementation of
location dereference protocol, such as the one described in the
location-dereference document. Maybe then we can move the URI schema
there and leave base HELD as simple as it was originally intended to be.
[/MB]

What it doesn't specify (and doesn't even normatively reference) is how
location by reference works. It's odd to have that in this document.
[MB] I'm not sure what "that is odd to have in this document".  As I
mentioned in my response at the top, we the locationURI and shemas
thereof  in this document because a parameter of that form can be
returned by the LIS when the HELD client requests a location by
reference. Per my note just prior, if we want to just say the
locationURI is a URI of any form, but may be restricted or further
specified by a location dereference protocol. [/MB]

-Ekr