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

Lisa Dusseault wrote:
> 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.
Yes. Understood.

Can somebody rephrase this is as a use case? I may not understand the 
geopriv stuff sufficiently to grok where the problem is.
The spec already defines a custom MIME type (good!).

Is the concern that a client that does a GET on an HTTP URI, and receive 
a response with that MIME type, still wouldn't know whether it's seeing 
a genuine HELD response, or just some static XML document served by a 
web server?
In that case I think a new response header, or some use of OPTIONS would 
be a simpler way to achieve that.
>  - 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.
As far as I can tell there are several problems with that:

- RFC2616 requires servers to understand requests with an absoluteURI as 
request-URI, but it also tells HTTP/1.1 clients not to use it (except 
when talking to proxies); so you're moving outside the HTTP/1.1 spec
- existing client libraries (such as XHR or Apache HttpClient) do not 
support this format (and why should they?), so how do you get the 
request on the wire if not by writing a custom http stack?
- how do you implement a server on top of existing HTTP frameworks, such 
as in a Java servlet container? Are there extension hooks that allow this?
So, has this been *tested*?

> 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.
Maybe, maybe not.

It would be helpful if somebody would explain why HTTP does not work 
here. For instance, where's the difference to WebDAV or AtomPub that 
requires a whole new identification scheme?
BR, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf