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

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Aug 2008 17:56:57 +0200

Hi,

I've read this document a few weeks ago, and I'm very concerned that it 
apparently wasn't reviewed by the HTTP and URI community.

I'm going to comment only on a few topics. I believe there are more 
things that need fixing, but let's focus on the important things first.

1) URI schemes

 From the draft, it's totally unclear what the URI schemes are needed 
for. For instance, the registrations do not mention what the URIs 
actually identity, and how to resolve them.

I also noticed that IANA missed the fact that there are new URI schemes 
to be registered 
(<https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-http-location-delivery/comment/80799/>).

2) HTTP examples

As far as I can tell, the examples in Section 11.1 are not really HTTP, 
or I'm missing explanations that would be needed to understand this.

For instance, they use heldref URIs in the Request-Line of the request. 
Also, there's an example where a response uses the HTTP version number 
"HTTP/1.x".

3) Usage of HTTP

The protocol tunnels over HTTP instead of using HTTP, probably because 
it tries to be transport-agnostic. This makes only sense if there are 
other transports. Are there?

Even if the answer to that is "yes", HTTP semantics should be obeyed; if 
the response to a request is an error message, it shouldn't be returned 
with status code 200. There's no problem using a 4xx class status code 
and returning a custom body (as we do in WebDAV).

Best regards,

Julian

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 4 Aug 2008 09:33:15 +0300

Hi Julian, 

Thanks for your review. 

>Hi,
>
>I've read this document a few weeks ago, and I'm very 
>concerned that it apparently wasn't reviewed by the HTTP and 
>URI community.

The document has received review from folks in the Application Area. 
In fact, the technical advisor for the group is Lisa. 

A lot of the suggestions came from the Applications Area. 

>
>I'm going to comment only on a few topics. I believe there are 
>more things that need fixing, but let's focus on the important 
>things first.
>
>1) URI schemes
>
> From the draft, it's totally unclear what the URI schemes are 
>needed for. For instance, the registrations do not mention 
>what the URIs actually identity, and how to resolve them.

Well. Initially, we wanted to use HTTP URI scheme but we were told that
we shouldn't do that. Based on the advice we got we created a new URI
scheme. 

They are resolved liked normallly HTTP URIs. 

They point to location information. 

>
>I also noticed that IANA missed the fact that there are new 
>URI schemes to be registered 

Thanks for the pointer. 

>
>2) HTTP examples
>
>As far as I can tell, the examples in Section 11.1 are not 
>really HTTP, or I'm missing explanations that would be needed 
>to understand this.
>
>Also, there's an example where a response uses the HTTP 
>version number "HTTP/1.x".

How would the examples have to look like so that they are correct? 

>
>3) Usage of HTTP
>
>The protocol tunnels over HTTP instead of using HTTP, probably 
>because it tries to be transport-agnostic. This makes only 
>sense if there are other transports. Are there?

The idea was to make it protocol agnostic and at least one other
transport has been published. Currently, the group tries to finish some
other work before these issues may be brought up again. 

>
>Even if the answer to that is "yes", HTTP semantics should be 
>obeyed; if the response to a request is an error message, it 
>shouldn't be returned with status code 200. There's no problem 
>using a 4xx class status code and returning a custom body (as 
>we do in WebDAV).

We copied this from other documents that went through the IETF process. 
We got told that returning a 200 OK is fine when the problem that caused
the error message happens to be at a different layer. So far, that
seemed to me like a pretty good answer and seems to be inline with the
semantic of protocol layering. 

Ciao
Hannes

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Aug 2008 08:45:17 +0200

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> ...
> ...

I think that's bad advice.

Either this decision should be reversed, or the specification needs to 
be updated so that it actually *defines* the URI scheme.

> ...

As far as I can tell,

          GET heldrefs://lis.example.com:49152/location HTTP/1.1
          Accept:application/held+xml,
              application/xml;q=0.8,
              text/xml;q=0.7
          Accept-Charset: UTF-8,*

needs to be:

          GET /location HTTP/1.1
          Host: lis.example.com:49152
          Accept:application/held+xml,
              application/xml;q=0.8,
              text/xml;q=0.7
          Accept-Charset: UTF-8,*

...which of course makes it obvious that the new URI scheme is totally 
pointless.

> ...

Is that discussion archived somewhere? Where did it happen?

BR, Julian

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 4 Aug 2008 09:51:16 +0300

Hi Julian, 

thanks for the extremely quick response: 

>> Well. Initially, we wanted to use HTTP URI scheme but we were told 
>> that we shouldn't do that. Based on the advice we got we 
>created a new 
>> URI scheme.
>> ...
>
>Either this decision should be reversed, or the specification 
>needs to be updated so that it actually *defines* the URI scheme.
>

Like with many other areas, you ask 5 persons and get 7 opinions. 
How should a working group soliciting advice make an informed decisions?

>> ...
>>> 2) HTTP examples
>>>
>>> As far as I can tell, the examples in Section 11.1 are not really 
>>> HTTP, or I'm missing explanations that would be needed to 
>understand 
>>> this.
>>>
>>> Also, there's an example where a response uses the HTTP version 
>>> number "HTTP/1.x".
>> 
>> 
>...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 ... 

Martin, can you provide a bit of background here? 

>>> because it tries to be transport-agnostic. This makes only sense if 
>>> there are other transports. Are there?
>> 
>> transport has been published. Currently, the group tries to finish 
>> some other work before these issues may be brought up again.
>> 
>>> Even if the answer to that is "yes", HTTP semantics should 
>be obeyed; 
>>> if the response to a request is an error message, it shouldn't be 
>>> returned with status code 200. There's no problem using a 4xx class 
>>> status code and returning a custom body (as we do in WebDAV).
>> 
>> We got told that returning a 200 OK is fine when the problem that 
>> caused the error message happens to be at a different layer. So far, 
>> that seemed to me like a pretty good answer and seems to be inline 
>> with the semantic of protocol layering.
>> ...
>

I have to search through the ECRIT and GEOPRIV mailing list -- 2 lists
with a lot of mail.

Ciao
Hannes

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Aug 2008 09:22:37 +0200

> How should a working group soliciting advice make an informed

If they got opinions their decision could be an informed guess.
In the case of the one to four held* schemes there was one URI
review request with one reply months ago, but possibly nobody
ever looked into it (?)

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Aug 2008 09:26:42 +0200

Hi Hannes,

> How should a working group soliciting advice make an informed decisions?

For once, I'd recommend to do it in a public place.

I note that Cullen asked for feedback on the uri-review mailing list 
(good!), but nobody sent feedback to Frank Ellermann who did comment on 
the URI issue (<http://article.gmane.org/gmane.ietf.uri-review/188>).

> since he also told me to update other drafts ... 

Interesting, looking forward to understand the reasons.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 09:41:37 +0200

Thomson, Martin wrote:
> Hi Hannes, Julian,
> 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.

Well. There's definitively a total disconnect between that IESG 
recommendation, and the W3C TAG's point of view (see ongoing discussion 
on the TAG mailing list about the "xri" scheme).

It would be good when both organizations could come up with consistent 
answers.

If a new URI scheme is defined, it needs to state what it identifies, 
and how it is resolved. If it identifies an HTTP resource, and 
resolution is done via HTTP, then it seems to me you don't need it.

This URI scheme seems to fall into the same category as Apple's iCal and 
iTunes related schemes, which aren't registered URI schemes for a reason.

> 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.

If the server is supposed to be able to differentiate (why?), then the 
URI identifies something else.

I'm not sure what problem you want to solve here. Could you elaborate? 
Isn't the custom MIME type + conneg totally sufficient?

Besides, how are you going to deploy this? What libraries allow you to 
put the full URI into the request line? How do you plan to deploy 
software that knows about the URI scheme?

> 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.)

Yes.

> 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.

That's true. So:

1) If the URI scheme is not equivalent to http(s), what's the 
difference? What is the resource being identified?

2) How do you intend to deploy the software that knows about this URI 
scheme?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 14:19:56 +0200

Julian Reschke wrote:
 > ...
>> 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.
> ...

I did some more investigation, and...

1) RFC2616 also states: "...even though HTTP/1.1 clients will only 
generate them in requests to proxies." -- which means, you can't use a 
conforming HTTP/1.1 client to produce them.

2) I tested with Apache 2.2.8, which seems to ignore the scheme. That 
seems to be a bug (raised: 
<https://issues.apache.org/bugzilla/show_bug.cgi?id=45579>).

3) I also tested with MS IIS 5.1, which immediately produces a 501 
status for unknown schemes.

BR, Julian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 5 Aug 2008 18:23:42 -0500

Hi Hannes, Julian,

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 6 Aug 2008 11:40:08 -0700

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:

> 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.)
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 20:59:54 +0200

Lisa Dusseault wrote:
> 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.
> 
> there was list email.  The issues that I was trying to help the WG address:
> 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.

> 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.
> 
> 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*?

> 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

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 6 Aug 2008 12:10:56 -0700

On Aug 6, 2008, at 11:59 AM, Julian Reschke wrote:

>
> 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?

Before that failure, there's the problem that a GET to a HELD server  
requires a custom body.  A GET without that body is undefined (in the  
last spec version I remember).

Another way to address this would be for a HELD server to be REQUIRED  
to respond to an empty-body GET with a "here's what you need to do  
with this URL" response, either user-readable or machine-readable  
(MIME type).  That could be part of an alternative to a HELD-specific  
URI scheme.

>
> - 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

That's OK, because HELD moves outside the HTTP/1.1 spec in several  
ways. A HELD client can be told to use the absolute URI, thus  
overriding the general-purpose requirement in 2616.  Extensibility  
sometimes requires these kind of defaults and exceptions.

>
> - 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?

This is a more serious problem.   Requiring a custom HTTP client stack  
would be drawback to the new-scheme approach.

>
>
> - 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?

I do not know if that's important to HELD server developers.

Lisa

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 6 Aug 2008 21:19:18 +0200

Lisa Dusseault wrote:

> given those caveats and the lack of an official IESG or IETF
> position on this

Dunno about the IESG, but I thought the IETF position is what
BCP 115 <http://tools.ietf.org/html/rfc4395#section-2.1> says:

"2.1 Demonstratable, New, Long-Lived Utility" [...] "New URI
 schemes SHOULD have clear utility to the broad Internet
 community, beyond that available with already registered
 URI schemes."

Possibly held: and helds: (or is it heldref: and heldrefs: ?)
are as they should be, but I didn't see this, and that's why
I asked.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 21:24:30 +0200

Lisa Dusseault wrote:
>> it's seeing a genuine HELD response, or just some static XML document 
>> served by a web server?
> 

Oh, I thought it uses POST, but maybe I missed something.

That issue was on my list anyway; I just didn't want to distract from 
the URI issue. A HELD request should be safe, so it probably would be 
good if it could always be put into a GET request (for instance, using 
query parameters).

> Another way to address this would be for a HELD server to be REQUIRED to 
> respond to an empty-body GET with a "here's what you need to do with 
> this URL" response, either user-readable or machine-readable (MIME 
> type).  That could be part of an alternative to a HELD-specific URI scheme.

As far as I can tell, the current spec always uses POST (not good for 
something that essentially is just a query), and allows GET as a 
fallback for the canonical case.

Yes, your proposal would work, but wouldn't it be much simpler to put 
the parameters into request-URI and always use GET?

>> - 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
> 
> That's OK, because HELD moves outside the HTTP/1.1 spec in several ways. 
> A HELD client can be told to use the absolute URI, thus overriding the 
> general-purpose requirement in 2616.  Extensibility sometimes requires 
> these kind of defaults and exceptions.

What I'm concerned with is that by doing so, you loose the ability to 
use available HTTP/1.1 client libraries.

> I do not know if that's important to HELD server developers.

Ok, are thesee extension hooks in Apache or IIS?

BR, Julian

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 6 Aug 2008 22:26:48 +0200

Lisa:

>> requires a custom body.  A GET without that body is undefined (in the last 
>> spec version I remember).

> Oh, I thought it uses POST, but maybe I missed something.

Section 9 of draft-08 seems to specify behavior for GET and
body-less POST as "MUST attempt to provide either a PIDF/LO document
or a Location URI".

Now, I don't know what "attempt" means in that context, but leaving
that point aside, it sounds to me like that's leaning into a
direction that could make the spec work perfectly well with a
browser as a client, assuming there's a handler for
application/held+xml.

The example in 11.1 uses a GET message without a body.

-- 
Thomas Roessler, W3C  <[email-masked]>  +33-4-89063488
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 22:38:04 +0200

> body-less POST as "MUST attempt to provide either a PIDF/LO document

    The use of HTTP/HTTPS also includes a default behaviour, which is
    triggered by a GET request, or a POST with no request body.  If
    either of these queries are received, the LIS MUST attempt to provide
    either a PIDF-LO document or a Location URI, as if the request was a
    location request.

Yes, that's why I was talking about. I don't see a requirement to use 
GET with a body (which would be an interesting experiment).

Yes.

As far as I understand, HELD is used to query for location information. 
Right now, the details of the query are encoded in a POST body as 
defined by the XML Schema in 
<http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08#section-7>. 
A GET works the same way as an empty POST request (as shown in 11.1).

This really smells like over-engineering.

Why aren't these things simple query parameters in a GET request?

BR, Julian

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Aug 2008 10:56:01 +0200

Julian Reschke wrote:
> recommendation, and the W3C TAG's point of view (see ongoing 
> discussion on the TAG mailing list about the "xri" scheme).
>
Note: I totally disagree.

I detest, abhor and condemn the idea that there is such a thing as a 
"HTTP resource".

An URI identifies a resource.

One possibility of accessing that resource is by using HTTP; if the URI 
scheme is "http:", there is an implication that the definer of the URI 
regarded this as the "normal" way of accessing the resource, and that 
whether the resource is static, dynamic or changeable is a matter 
strictly under the control of the manager of the server identified by 
the hostname in the URI.

Certain usages of HTTP (in particular, the use of HTTP URLs for XML 
schemas) have tended to denigrate this implication, and say "you should 
regard this as an identifier". Still, the usage is prevalent enough that 
people have complained that servers identified in popular XML schemas 
are getting hit with enough extra traffic to cause operational problems.

Now, many resources can be accessed over HTTP. And many more will be.
But in many cases, the guarantees given should be DIFFERENT; a "mid:" 
URI means that "if you find a copy of the message with this message-ID, 
it's probably the same message" - a "tag:" URI means "someone intended 
this URI to be an unique reference, and you can figure out who it was 
given enough time and effort". And I haven't even mentioned URNs yet.

The WG needs to be clear about what kinds of resources it's identifying, 
and what the properties it wants to embed as part of the URI scheme is. 
Usually, "all the features and warts of HTTP" won't be the answer.

I don't speak for anyone but myself. But just based on Julian's 
comments, I stand with the IESG advice on this one, and think that the 
W3C TAG (if its recommendation is reported correctly) is off in the weeds.

               Harald

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 7 Aug 2008 11:02:10 +0200

On 7 aug 2008, at 10.56, Harald Alvestrand wrote:

>> If a new URI scheme is defined, it needs to state what it  
>> identifies, and how it is resolved. If it identifies an HTTP  
>> resource, and resolution is done via HTTP, then it seems to me you  
>> don't need it.

FWIW: I agree with this. A URI is an identifier. Some of them might be  
possible to resolve using for example information given by the URI  
scheme, but that is definitely not a requirement. And it has never  
been one either.

    Patrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 11:24:50 +0200

Hi Harald.

> Note: I totally disagree.

Interesting, as most of what follows is something I *do* agree with :-)

The point I was trying to make is that when a specification defines a 
new URI scheme, it should be able to state what it identifies, and, if 
it's intended to be resolvable, how that resolution process works.

This information isn't present in the HELD draft.

> I detest, abhor and condemn the idea that there is such a thing as a 

I was using "HTTP resource" as in "something identified by an HTTP URL".

Yes.

Yes.

> are getting hit with enough extra traffic to cause operational problems.

I've heard that as well, and tried to find out exactly *what* URLs were 
causing the problem. As far as I can tell, it was always because of URLs 
that were intended to be dereferenced, such as URLs of DTDs. (If this is 
incorrect, I'd love to see a pointer...).

Yes.

> and what the properties it wants to embed as part of the URI scheme is. 

Yes. This is what I was saying, wasn't I?

> W3C TAG (if its recommendation is reported correctly) is off in the weeds.

It seems to me that you have been reading something into my comments 
that isn't there.

HELD (as in draft 08), defines two new URI schemes, does not define what 
they identity, does not state how to resolve them, and has examples 
using untested HTTP/1.1 features for resolution.

That's why I was asking whether a new naming scheme really is needed *here*.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 11:26:05 +0200

Patrik Fältström wrote:
> scheme, but that is definitely not a requirement. And it has never been 
> one either.
> ...

Just for the record: I agree with this, and didn't say anything else.

BR, Julian

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Aug 2008 11:31:49 +0200

it's surprising how much we agree on :-)

Julian Reschke wrote:
>> schemas) have tended to denigrate this implication, and say "you 
>> should regard this as an identifier". Still, the usage is prevalent 
>> enough that people have complained that servers identified in popular 
>> XML schemas are getting hit with enough extra traffic to cause 
>> operational problems.
>
> I've heard that as well, and tried to find out exactly *what* URLs 
> were causing the problem. As far as I can tell, it was always because 
> of URLs that were intended to be dereferenced, such as URLs of DTDs. 
> (If this is incorrect, I'd love to see a pointer...). 
Is it clearly stated somewhere that URLs of DTDs are intended to be 
dereferenced?
(in the Murky Old Days we had DTDs identified by SGML identifiers, which 
I don't think I'll be able to dereference any time soon....)

                Harald

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 11:44:33 +0200

> Is it clearly stated somewhere that URLs of DTDs are intended to be 

Well, an XML processor needs to read a DTD if it doesn't already have a 
copy of it (you can opt-out of that using the "standalone" declaration, 
but that's not the default, see text around 
<http://www.w3.org/TR/xml/#sec-rmd>).

> I don't think I'll be able to dereference any time soon....)

Best regards, Julian

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 7 Aug 2008 13:13:15 +0300

I was asked to provide some pointers related to the design decisions we made in GEOPRIV. The GEOPRIV mailing list is a high-volume list and hence it is not fun to search through it. Anyway, I found some pointers of interest. 

Ted Hardie provided me with a few pointers around the URI scheme discussion: 
http://www.ietf.org/proceedings/08mar/minutes/geopriv.txt

James Winterbottom pointed me to the mailing list thread I started some time ago:
http://www.ietf.org/mail-archive/web/geopriv/current/msg04602.html

Here is another mailing list thread related to this topic: 
http://www.ietf.org/mail-archive/web/geopriv/current/msg05567.html

Reading through the mails again I unfortunately cannot find a strong recommendations. It seems that reading through RFC 3205 we got confused.

Initially, the entire discussion started with LoST where we also solicited review for a URI scheme, see 
http://www.ietf.org/mail-archive/web/uri-review/current/msg00601.html

I was pointed to RFC 3205 but we later decided not to define a lost URI scheme. 

In KEYPROV we ran into a similar issue. I also asked for review:
http://www.ietf.org/mail-archive/web/apps-review/current/msg00082.html
Here is the mailing list thread that resulted from my request for review: 
http://www.ietf.org/mail-archive/web/apps-review/current/msg00084.html

In that specific review request the issue of separate port numbers came up.

As one can seen from the mailing list discussions I was not in favor of defining a new URI scheme for HELD. Maybe we can/should reverse that decision...

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Patrik Fältström
>Sent: 07 August, 2008 12:02
>To: Harald Alvestrand
>Cc: Julian Reschke; IETF Discussion; Thomson, Martin
>Subject: Re: New schemes vs recycling "http:" (Re: Past LC 
>comments ondraft-ietf-geopriv-http-location-delivery-08)
>
>identifies, 
>FWIW: I agree with this. A URI is an identifier. Some of them 
>might be possible to resolve using for example information 
>given by the URI scheme, but that is definitely not a 
>requirement. And it has never been one either.
>
>    Patrik
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 12:48:30 +0200

Hannes,

thanks for the pointers....

> I was pointed to RFC 3205 but we later decided not to define a lost URI scheme. 

For the record, there was some discussion in the appsarea meeting in 
Vancouver about updating BCP56 (RFC3205).

I think if the conclusion from reading it is that you need new URI 
schemes and port numbers for anything "beyond webbrowsing", then that 
definitively does not represent IETF consensus (as of today) or the 
state of the art, or even recent IETF specifications (CalDAV, AtomPub, 
whatnot).

Best regards, Julian

---

From: "Tim Bray" <[email-masked]>
Date: Thu, 7 Aug 2008 09:05:20 -0700

On Thu, Aug 7, 2008 at 1:56 AM, Harald Alvestrand <[email-masked]> wrote:

>> recommendation, and the W3C TAG's point of view (see ongoing discussion on
>> the TAG mailing list about the "xri" scheme).

That discussion is just too long and gnarly to summarize, but without
touching on any of the actual technical issues:

There is a strong perception among quite a few people, notably
including the TAG, that the XRI people don't understand the
technologies they're trying to replace; many of their statements
beginning "XRI is needed because..." have been challenged as being
simply technically wrong.

The TAG is in fact clearly correct when they state that introduction
of new URI schemes is quite expensive.  So it comes down to a matter
of cost/benefit, and a lot of people are not convinced that a real
benefit has been established for XRI, relative to the existing Web.

>> If a new URI scheme is defined, it needs to state what it identifies, and
>> how it is resolved. If it identifies an HTTP resource, and resolution is
>> done via HTTP, then it seems to me you don't need it.

Actually, no.  There are lots of identifiers that do not have a
"resolution" requirement.

> Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas)
> have tended to denigrate this implication, and say "you should regard this
> as an identifier". Still, the usage is prevalent enough that people have
> complained that servers identified in popular XML schemas are getting hit
> with enough extra traffic to cause operational problems.

This has happened, usually due to clueless implementors.  The most
famous case is the DTD URIs appearing in the HTML <!DOCTYPE>, which
certain developers who will remain nameless tried to retrieve every
time they parsed an HTML page.  Surprise surprise, it didn't work.

It's a real risk.  Any identifier that can be used to retrieve
something will so be used, whether that's appropriate or not, and
that's a risk we have to work into our plans.

 -Tim

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 7 Aug 2008 09:24:19 -0700

On Aug 7, 2008, at 3:48 AM, Julian Reschke wrote:

>> Reading through the mails again I unfortunately cannot find a  
>> strong recommendations. It seems that reading through RFC 3205 we  
>> got confused.
>> Initially, the entire discussion started with LoST where we also  
>> solicited review for a URI scheme, see http://www.ietf.org/mail-archive/web/uri-review/current/msg00601.html
>> I was pointed to RFC 3205 but we later decided not to define a lost  
>> URI scheme. ...
>
> schemes and port numbers for anything "beyond webbrowsing", then  
> that definitively does not represent IETF consensus (as of today) or  
> the state of the art, or even recent IETF specifications (CalDAV,  
> AtomPub, whatnot).

Although I agree with a lot of the tradeoff advice being given in this  
thread, I'm not sure if HELD is really the same kind of thing as  
CalDAV or AtomPub.   The latter definitely involve Web servers holding  
all kinds of resources that any HTTP client can download with a simple  
GET and, thanks to the content types, have a chance of using  
application content in a reasonable way.  CalDAV and AtomPub both make  
use of other parts of HTTP like DELETE and PUT or POST, caching and  
auth and cookies. They are really extensions to HTTP to use HTTP for  
special applications.

I'm not certain how the designers of HELD view HELD.  If it were an  
extension of HTTP for helping clients access, use and maybe author Web  
resources which happen to be location documents, that philosophical  
position certainly implies use of the http scheme and other REST ful  
decisions.

However, if the designers view HELD as using HTTP as a request/ 
response transport to a service that is not otherwise a Web server,  
then that implies a different approach.  I'm not against using HTTP  
for this, but when that road is taken I try to help the protocol from  
suffering from interoperability problems due to ignoring all the extra  
features of HTTP that the spec writers probably don't initially think  
about using or disabling.  E.g. see http://tools.ietf.org/html/rfc5055#appendix-B 
  -- which could still be improved upon to the benefit of interop --  
it narrows down what features of HTTP can be used or can be assumed to  
be supported.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 18:47:32 +0200

> "resolution" requirement.

Correct. I was sloppy.

However, in the context of HELD it stays true, as the identifiers 
*clearly* are intended to be resolvable (as they are used for location 
requests, and the whole document would be totally pointless if there was 
no way to resolve them).

> time they parsed an HTML page.  Surprise surprise, it didn't work.

Right. RSS vs Netscape is another example.

Using public URIs for DTDs introduces a single point of failure. Using 
public URIs for XML namespaces do not, because processors do not *need* 
to resolve them.

> that's a risk we have to work into our plans.

Correct. That being said, do we have any evidence that URIs that appear 
as XML namespace names (and *only* there) have caused this kind of problem?

BR, Julian

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Aug 2008 18:06:34 +0100

On Wed, 6 Aug 2008, Lisa Dusseault wrote:
>
> Before that failure, there's the problem that a GET to a HELD server requires
> a custom body.

RFC 2616 says "A message-body MUST NOT be included in a request if the
specification of the request method does not allow sending an entity-body
in requests." So I think including a body in a GET request is not allowed.
However RFC 2616 is also not very explicit about request bodies in the
method specifications.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
DOGGER FISHER GERMAN BIGHT HUMBER: CYCLONIC 4 OR 5, BECOMING NORTHERLY OR
NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN GERMAN BIGHT. MODERATE
OR ROUGH. RAIN OR SHOWERS, FOG PATCHES AT FIRST, MAINLY FAIR LATER. MODERATE
OR GOOD, OCCASIONALLY VERY POOR AT FIRST.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Aug 2008 19:22:23 +0200

> in requests." So I think including a body in a GET request is not allowed.

That's why we have the HTTPbis WG :-)

"Bodies on GET (and other) requests" -- 
<http://tools.ietf.org/wg/httpbis/trac/ticket/19>

Resolution:

--- snip ---
Consensus to, in RFC2616 section 4.3:

     * Change "does not allow" to "explicitly disallows", as per 
http://www.w3.org/mid/[email-masked]
     * Replace the last sentence with:

         When a request message contains both a message-body of non-zero 
length and a method that does not define any semantics for that request 
message-body, then an origin server SHOULD either ignore the 
message-body or respond with an appropriate error message (e.g., 413). A 
proxy or gateway, when presented the same request, SHOULD either forward 
the request inbound with the message-body or ignore the message-body 
when determining a response.

as per http://www.w3.org/mid/[email-masked]
--- snip --

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2008 13:23:23 -0400

Tim Bray wrote:

> of new URI schemes is quite expensive. 

To me it seems that this depends on the extent to which those new URI 
schemes are to be used in contexts where existing URI schemes are used. 
  New URI schemes used in new contexts or applications are not overly 
burdensome.

It should also be recognized that overloading URI schemes (as well as 
overloading HTTP) is also expensive, though in a different way.  The 
consequence of overloading is that functionality is reduced and 
interoperability suffers.

Keith

---

From: "Tim Bray" <[email-masked]>
Date: Thu, 7 Aug 2008 10:47:53 -0700

On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore <[email-masked]> wrote:

> schemes are to be used in contexts where existing URI schemes are used.  New
> URI schemes used in new contexts or applications are not overly burdensome.

Right, but there's a contradiction lurking here.  You probably
wouldn't bother to use URI syntax unless you expected fairly wide
utilization, or to benefit from the plethora of existing URI-parsing
and -resolving software.  The notion of wanting to use URI syntax but
simultaneously requiring a new scheme is often a symptom of fuzzy
thinking.

And in the specific case of XRI, which seems designed as an extremely
general-purpose thing, the cost is clearly very high, so the benefits
need to be compelling.

> interoperability suffers.

Got an example?  I'm having trouble thinking of any problems I've run
across that could be ascribed to this.  -Tim
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2008 14:38:48 -0400

Tim Bray wrote:
>>> The TAG is in fact clearly correct when they state that
>>> introduction of new URI schemes is quite expensive.
>> To me it seems that this depends on the extent to which those new
>> URI schemes are to be used in contexts where existing URI schemes
>> are used.  New URI schemes used in new contexts or applications are
>> not overly burdensome.
> 
> and -resolving software.

Disagree.  Neither wide utilization, nor ability to reuse existing
software were ever necessary to make URIs useful.   A compact notation 
for naming resources (and in some cases, suggesting how those resources 
can be accessed) is useful in its own right to almost any networked
application, even if it has to implement its own URI parsing routines,
and even if it doesn't utilize the HTTP infrastructure at all.

Also, URIs have mindshare, the value of which should not be
underestimated.  People all over the world are used to dealing with them
and - at some level - understand their limitations.

> The notion of wanting to use URI syntax but simultaneously requiring
> a new scheme is often a symptom of fuzzy thinking.

If URIs were a good idea in the context of the web, it's hardly
surprising that they might be a good idea in the context of other 
networked applications.

>  general-purpose thing, the cost is clearly very high, so the
> benefits need to be compelling.

I haven't followed XRI enough to have an opinion about it.

>> It should also be recognized that overloading URI schemes (as well
>> as overloading HTTP) is also expensive, though in a different way.
>> The consequence of overloading is that functionality is reduced and

The most obvious example that comes to mind is that protocols tend to 
evolve separately from one another, even when derived from a common 
ancestor - and the scope/applicability of each protocol is likely to 
change over time.   Whenever any protocol (including HTTP) is adapted 
for some application that is sufficiently removed from its "normal" use, 
and especially if that new application itself attracts a lot of users or 
implementations, there is a tendency to "tweak" that original protocol 
to better align it with the new application.   For instance, we can see 
how this has happened with email message headers when they've been 
adapted to NetNews and HTTP requests and responses.   (It also happened 
when RFC 822 was adapted for use on BITNET and UUCP networks). If the 
protocol being adapted is HTTP, and HTTP URIs are used to name resources 
in the new application, interoperability of HTTP URIs will suffer.

Keith

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 7 Aug 2008 15:55:52 -0700

On Aug 7, 2008, at 10:47 AM, Tim Bray wrote:

> On Thu, Aug 7, 2008 at 10:23 AM, Keith Moore <[email-masked] 
> > 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.

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

---

From: "Tim Bray" <[email-masked]>
Date: Thu, 7 Aug 2008 16:25:28 -0700

On Thu, Aug 7, 2008 at 3:55 PM, Lisa Dusseault <[email-masked]> wrote:

> install an application which registers

Well, yeah, but a lot of the infrastructure is deployed on dumb
devices and, more important, if you stick to existing URI schemes and
use them properly, it All Just Works.

I know it seems like Those Web Guys Hate URI Schemes, and I get tired
of quoting http://www.w3.org/TR/webarch/#URI-scheme at people, and I
admit being prejudiced by the fact that a high proportion of
new-uri-scheme proposals have historically been poorly-considered (not
all, see RFC4151).  But there's no getting around it: the cost of new
schemes is very high, if you want to be part of the Web.

  -Tim

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2008 19:47:18 -0400

Tim Bray 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
> 

That's ridiculous.

First of all it's not as if HTTP is an optimal or even particularly
efficient way of accessing all kinds of resources - so you want to
permit URI schemes for as many protocols as can use them.

Second, user agents and other tools that use URIs glean valuable
information from the differences between URI schemes, and they do so
without having to negotiate protocol details.  Granted you don't want to
make every clue that a UA might benefit from visible in the URI scheme.
  But it's silly to say that existing URI schemes are sufficient for all
purposes.

> new-uri-scheme proposals have historically been poorly-considered
> (not all, see RFC4151).

No doubt.  Then again, most proposals of any kind are poorly considered.

(And IMHO the advice in the webarch document about URI scheme reuse is, 
as kindly as I can put it, so over-simplified as to be incorrect.)

> But there's no getting around it: the cost of new schemes is very
> high, if you want to be part of the Web.

If you adopt a fairly narrow view of the web, perhaps.

Keith

---

From: "Tim Bray" <[email-masked]>
Date: Thu, 7 Aug 2008 18:04:08 -0700

> permit URI schemes for as many protocols as can use them.

Well, it's not as if the presence of the "http:" scheme requires you
to use the protocol, and in fact a very high proportion of all
accesses to such resources go sideways through various caching schemes
and so on.   The notion that the scheme implies the protocol is a
common and very old misconception.

>  But it's silly to say that existing URI schemes are sufficient for all

Nobody has ever said such a thing.  I and others have repeatedly
argued that one or another specific proposal for a new URI scheme has
a lousy cost-benefit ratio.  That is the totality of this debate.  -T
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Aug 2008 21:34:35 -0700

>common and very old misconception.

How did you measure the accesses to arrive at the conclusion
that a very high proportion of all such accesses to such
resources "go sideways through various caching schemes
and so on"?  Can you elaborate on what "and so on" means
here?

On your other point, the accuracy of the idea that the scheme
"implies the protocol" varies enormously.  Some schemes
are nearly pure identifier, without strong bindings to
a specific dereferencing protocol ( "tag" and "info" come
to mind).  But some schemes really do have a very
strong binding to specific protocol mechanics and
a specific URI in those schemes amount to instructions
as to how to engage in that.    See RFC 4501 for an example.
It defines the "dns" uri scheme,  using a
scheme definition that has a very explicit usage
model and that describes the common resolution mechanism
using the DNS.   It retains the point that other
resolution mechanisms are possible, but how to
use it in a DNS context is both quite clear and quite
clearly understood to be the common case.

			regards,
				Ted

---

From: Keith Moore <[email-masked]>
Date: Fri, 08 Aug 2008 01:45:52 -0400

> common and very old misconception.

But it's not a misconception.  In the vast majority of contexts if you 
name a resource using an HTTP URI then it's expected that if that 
resource is at all accessible over the Internet, it's accessible via 
HTTP using the information in that URI.

> a lousy cost-benefit ratio.  That is the totality of this debate.  -T

I am sure that many URI proposals have poor cost-benefit ratios.  That's 
reason to give them scrutiny, but not a reason to reject the idea of 
having new URI types, nor to overload existing URI types.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Aug 2008 08:22:50 +0200

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 11 Aug 2008 09:51:34 -0400

Hi Julian,

> Why aren't these things simple query parameters in a GET request?

The short answer is that the WG (and the HELD authors in particular) 
perceive a need for this protocol to have an extensible request syntax.

This document (-http-location-delivery) defines a very basic 
request-response container for location-request and -response messages. 
  In this basic form, it supports the simple case where the HELD server 
can determine the client's location based only on the client's IP address.

Often, however, the HELD server requires additional information to 
determine the client's location.  The most basic example of this is when 
the HELD server computes the client's position based measurements of the 
network, such as 802.11 signal strength measurements.  These 
measurements could be embedded into a HELD request using the extensions 
to the XML request syntax defined in the following draft:
<http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements>
<http://tools.ietf.org/html/draft-thomson-geopriv-wimax-measurements>

It's fair to note that the WG has not adopted any HELD extensions as WG 
documents.  However, GEOPRIV is currently considering whether to adopt 
them, so it seems to make sense to provide a simple way to extend the 
request syntax.

Cheers,
--Richard