Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08

I believe I instigated the creation of a new URI scheme for HELD.   
That's not to say, however, that I or the IESG required that solution  
-- to elaborate on what Martin said, I raised some issues, and the URI  
scheme was added after my review, but other solutions might work  
instead of new URI schemes.
The discussions started in a bar in San Diego (unminuted). After that  
there was list email.  The issues that I was trying to help the WG  
address:
 - When an HTTP URI is found in an email, blog, etc, the operating  
system launches a Web browser.  However, a Web browser doesn't know  
how to formulate a HELD request, and even if it did know how, it  
wouldn't know when/whether.
 - When location URIs appear in another context -- let's say, another  
protocol or a data format -- it can be helpful to be able to limit  
what kind of URIs appear in that context.   Limiting by saying "These  
URIs must be of this URI scheme" is an easy way to do so.
Both of these problems can be solved in other ways besides defining a  
new URI scheme.
That said, a new URI scheme does help with both problems, and it does  
highlight the issue that most regular HTTP requests (e.g. a GET  
without a body) are not standardized or interoperable under HELD.  It  
should be OK to use a new URI scheme in the target of an HTTP request,  
after all that's a well-defined point of HTTP extensibility in theory,  
and I'm not aware of major client or server library limitations that  
would prevent use in practice.  If it has to be made explicit in the  
document that defines the URI schemes, so be it -- I believe it was  
implicit but obvious.
I'm aware of the W3C TAG recommendations on new URI schemes.  Their TR  
says " Good practice: Reuse URI schemes.  A specification SHOULD reuse  
an existing URI scheme (rather than create a new one) when it provides  
the desired properties of identifiers and their relation to resources."
Some of their notes say for example: "You need to demonstrate there is  
a bar for URIs [new schemes] doing what you want or there is a huge  
value add".  We can debate whether this example is a big value-add and  
whether the HTTP URI fails to express that a client needs to do a  
custom GET request, but given those caveats and the lack of an  
official IESG or IETF position on this, I believe there's some  
consistency between W3C TAG recommendations and IETF usage, and  
potentially this specific usage.
Lisa

On Aug 5, 2008, at 4:23 PM, Thomson, Martin wrote:

> Hi Hannes, Julian,
>
> > > > ...which of course makes it obvious that the new URI scheme is
> > > > totally pointless.
> > > We just recently updated our examples from the lower one to the  
> > > upper
> > > one. Martin Thomson might provide you more background on this issue
> > > since he also told me to update other drafts ...
> > Interesting, looking forward to understand the reasons.
> >
> > > Martin, can you provide a bit of background here?
> > > ...
> I'm impartial on the topic of URI schemes.  The URI scheme was added  
> on request after IESG review.  There were concerns about the loss of  
> contextual information relating to the URI when used in contexts  
> outside the context of the Device-LIS exchange.
> Assuming that the URI is necessary...  The reason to go with the  
> full URI on the request line is to ensure that the server is able to  
> distinguish between a held[s]: URI and a matching http[s]: URI.   
> Without this, the server potentially does not know the difference.
> Without the absolute URI, there is the possibility that held: and  
> http: URIs could be considered equivalent.  In fact, there would be  
> no meaningful difference when it comes to the protocol exchange, as  
> you rightly pointed out.  (I'll note that this isn't the only  
> difference that is important, and certainly wasn't a factor in the  
> discussions that lead to the introduction of the new scheme.)
> Using an absolute URI is not common practice in HTTP for anything  
> other than requests to proxies.  However, RFC 2616 requires that  
> servers understand and support absolute URIs (Sec. 5.1.2).  In my  
> experience, this is a safe thing to assume; HTTP servers generally  
> treat the URI sensibly.
> Cheers,
> Martin
>
> ------------------------------------------------------------------------------------------------
> 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]
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf