Lisa Dusseault wrote:
Don't browser and OS libraries dispatch on URI scheme? I guess it's
probably not as easy to extend as adding a new handler for a new
Content-Type, but it's at least possible for a new URI scheme to start
appearing (in email, Web pages, local docs, etc) and for the user to
install an application which registers for handling that scheme, and
suddenly they have new functionality without upgrading the OS or browser.
At least for Windows that is true.
To me, that's a pretty compelling and unfuzzy benefit. It doesn't apply
to all proposed new URI schemes, but it arguably does for HELD.
Lisa, I still have trouble understanding the use case. Why would a user
*ever* want to follow a heldref URI, and have a custom application come up?
<http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08>
states:
This specification defines an extensible XML-based protocol that
enables the retrieval of LI from a LIS by a Device. This protocol
can be bound to any session-layer protocol, particularly those
capable of MIME transport. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
Security (HTTP/TLS) as transports for the protocol.
So my understanding is:
- client obtains the URI of a LIS (Location Information Server)
- client uses this protocol to obtain Location Information (LI) from
that LIS
The locationRequest currently has exactly *two* parameters, locationTime
(a timeout value), and locationType (a keyword). What I am trying to
understand is why we need a 48 page spec to define something that could
easily be a single GET request to an HTTP URI with two query parameters.
(The MIME type for the response format is fine)
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
