Subject: Re: [Geopriv] HELD -04 Issue 2: Document Structure

From: Richard Barnes <[email-masked]>
Date: Thu, 07 Feb 2008 17:15:03 -0500

Mary,

Given that nobody on the list seems to feel strongly either way, I'm 
willing to grant that the text is clear enough as it stands.

--Richard

Mary Barnes wrote:
>  
> 2. Document structure
> Throughout most of the document, HELD is discussed as a single,
> integrated protocol, the notable exceptions being Section 5.1 and
> Section 8.  On the other hand, there are clearly two separate components
> to the protocol: The XML syntax, the transport/binding protocol.
> 
> The current draft needs to describe better the functions played by these
> parts individually as well as together.  This is crucial because as HELD
> is extended, these two parts will be used with different parts;
> different XML (e.g., adding identitifierss or measurements) over HTTP,
> or the same XML messages over other bindings (e.g., raw TLS, BEEP). 
> (Obviously the first case is more likely!)  It will be easier to to make
> extensions secure and interoperable if the roles of the XML syntax and
> the binding are clearly articulated.  In addition, I think this will
> make the current draft easier to understand.
> 
> Consider target identifiers: It isn't clear from the current draft (at
> least to me) that the XML has nothing to do with the identifier used for
> the target; instead, the identifier is provided by the transport layer. 
>     If you're implementing a LIS, this tells you to get the identifier
> from the whatever transport component you're using.  If you're writing
> an extension that runs over a new transport, it tells you that you need
> to specify an identifier to use.  If you're writing
> draft-winterbottom-geopriv-held-identity-extensions, it tells you that
> you need to explain how your XML identifiers interact with the
> identifiers the transport layer provides.
> 
> I don't mean to propose a radical re-writing of the document; I think
> most of the text is already there.  I'd just like to see it organized
> differently:
> a. Syntax/semantics included in the XML
> b. Syntax/semantics included in the binding c. How the HTTP binding
> works in particular
> 
> 
> [MB] I can't see what a huge advantage this proposal provides - I can't
> see that it  (XML versus HTTP binding) isn't fairly clear at this point.
> We could move 5.1 into section 8 to isolate the HTTP binding to a single
> section, but I think the device id is an important concept that belongs
> in the protocol description (section 5), which IS independent of
> transport. In my view, it's quite clear that at this point, there is no
> identifier provided by the XML, because there is no identifier defined
> in the XML. We can certainly add some more text to the HTTP section to
> clarify your point if you can provide the text (again, I can't see what
> might be missing).  [/MB]
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 22 Feb 2008 17:34:52 -0600

This is the other issue that may not be totally resolved in the -05.  I
did follow Martin T. and James W's suggestions for the most part on
changes to the URI itself and put the details in an entirely separate
section. However, I have left the informational references to the deref
document as I think that is required for describing the protocol usage
of this URI scheme.  There should not be an issue with these informative
references impacting the progress of HELD (i.e., they won't be
downrefs). 

If folks are okay with that approach and are okay with the new schema
for the URI, this issue is closed.

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Thursday, January 31, 2008 2:50 PM
To: Richard Barnes; GEOPRIV
Subject: [Geopriv] HELD -04 Issue 1: HELD URI

Richard,

My comments are embedded below [MB]:

========================================================================
================

1. HELD URI
The specification of a HELD URI scheme in the current draft seems
incomplete, in that it doesn't fully specify a dereference scheme. 
However, specifying a dereference scheme would essentially make
draft-winterbottom-geopriv-deref-protocol a part of the HELD
specification.  That is, if the HELD URI were completely specified, the
base HELD spec would specify not only an LCP usage of HELD but also a
location-by-reference usage.

On the other hand, I haven't heard a compelling reason that a HELD URI
is necessary if the only supported use case is an LCP.  In that case, it
seems sufficient for the endpoint simply to acquire a DNS name or IP
address for the LIS, so that it can send a HELD/HTTP request to port 80
on that interface (the Request-URI could be fixed in the standard, e.g.,
"/").  So if we only want the current draft to support the usage of HELD
as an LCP, the HELD URI can be removed altogether.

So I think there are two alternatives:
a. Completely specify the HELD URI, including dereference by 3rd parties
b. Remove the HELD URI from the draft and only support the LCP usage My
personal preference is for the former, but I don't have any strong
objections to either option.  However, we should decide on one of these
two course

[MB] I think there's a 3rd alternative c. which is a variation of what
you suggest for a.. For alternative c., I would propose to put the
complete specification of the HELD URI in another document and have both
the HELD and the dereference document reference that document.  This
should not dramatically slow down the progress of the HELD document and
would allow us to complete HELD while tidying up the details for the
schema. 

I don't think b. is viable given that there has already been WG
consensus that the HELD URI is needed.  Alternative c. is what I had
proposed previously to avoid the references to the dereference document
that James W. did not want in HELD. My understanding is that if we have
the schema registration in this document, we need at least an
informational reference to the deref specification since it will be a
user of the schema.  I'm cc'ing Lisa Dusseault on this one as perhaps
she can clarify that latter point.   
[/MB]