Subject: [Geopriv] HELD-04 and HELD URIs

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Jan 2008 19:08:46 -0600

Hi Mary,

OK, so both James and I have had comments on the HELD URI, and rather than defer it, we should just address the problem.  Besides, we need a definition for lis-discovery, so I don't think that we can just put it off, tempting as that sounds.

There are two use cases for a HELD URI:

 * As the result of a discovery process, the HELD URI tells a Device where to go to get location information.

 * As a location URI, the HELD URI tells a Location Recipient (LR) where to get location information for a Target.

An important thing to note is that a HELD URI is not necessarily a location URI, although it may be.  Furthermore, a location URI does not have to be a HELD URI - as long as we understand how to resolve the URI and get a PIDF-LO, any URI scheme is acceptable (sip:, https:, pres:, gopher:, etc...)

(You could probably put text to this effect in the document.  Informative references here to lis-discovery and held-deref should be sufficient.)

I'll respond specifically to your comments and later provide some suggestions.

 [MB->AJW] My understanding of the general requirements and guidelines for the URI schema registration (RFC 4395) is that you should list all the protocols that can use the schema, so the reference [to the held-deref draft] is needed for this document for that situation, so I don't think it hurts to leave it in this document.  ...[/MB]

Let's make it informative - deref isn't a WG item at the moment ('though it should be) so a normative reference would slow things down a great deal.

...[MB] Or, we need to consider defining the URI schema in a separate document altogether (not an uncommon thing to do).  That's fine if the group wants to restrict the URI to that single form. ...[/MB]

The only reason I'm against this is that the URI needs to be available for lis-discovery.  That would be the only other place that I would consider.  Any other document would delay our dates.

...[MB] It seemed useful to me to have more flexibility and extensibility (e.g., a LIS may want to embed more than a single random token or more specific information in the URI). If folks don't think that's necessary, I'll remove. [/MB]

I'll explain in more detail why I think this is bad below...

[MB] By definition, there is enough detail, per the ABNF, to implement a
deferencer, so that's not the isse.  ...[/MB]

I think I get where you were going.  Technically, you _can_ send an HTTP request with an absolute URI:

  GET held://location-id@host:port/path?extension HTTP/1.1
  Host: host

But it's rare to do that for HTTP.  For HELD, the server has to be able to understand where to send the query.  Since the URI sort-of looks like HTTP, this works in some cases.  It will depend on the HTTP server that you use to implement the service.  Apache+PHP can handle this gracefully and somewhat usefully; they can even set _SERVER['QUERY_STRING'].  I'm not sure that other servers will, and it doesn't work for static pages on Apache.

The field that I have a problem with is the location-id.  This matches the user-id of the HTTP URI and could possibly interfere with any authentication that the server might be doing.  If you were to drop this field, I'd be happy.

...[MB] We actually need to include an explicit schema in this doc if we want one, so we can't reference RFC 2616 and then say except, etc. )  The one I proposed is simpler than others and similar to some others. But, per my response to James, if folks don't see the need for flexibility or extensibility, we can make far simpler. I am using RFC 3986 definitions except for the token and extensibility aspects. ...[/MB]

I don't see why you can't use the RFC 3986 definitions for the path and extensions.  That's easier.  The entire path should be opaque.

...[MB]  Are you suggesting that we use the fragment for the "random token"? [/MB]

Nope, it was an oversight.  A fragment has special meaning and couldn't be relied upon to be used reliably.  We'd need to define how to interpret it for the media type if we don't already inherit the rules from XML (XPointer perhaps).

Here are my suggestions:

 * Please move the section on the HELD URI to its own section.  A major section number wouldn't hurt.

 * Add the specific use cases for the URI: discovery and deref (see top of email).

 * Include note that HELD URI and location URI are not synonymous (see top).

 * Please remove the location-id from the HELD URI.

 * You should also update the examples to include an absolute URI.  Note that standard HTTP/1.1 clients are expected to generate requests with absolute URIs only when they are querying a proxy, so this is somewhat unusual behaviour.  This should be OK, although it wouldn't hurt to note that HELD servers should be liberal in what they accept and interpret requests that contain http URIs (or just an absolute path) as HELD requests if they have the application/held+xml content.

Thanks,
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv