headers
Larry Masinter | 2 Jan 2010 19:52
Picon
Favicon
Gravatar

FW: ftp URI scheme is where?

I mistyped the mailing list address... 

-----Original Message-----
From: NARUSE, Yui [mailto:naruse <at> airemix.jp] 
Sent: Saturday, January 02, 2010 10:49 AM
To: Larry Masinter
Cc: public-iri <at> w3.org; uri <at> we.org
Subject: Re: ftp URI scheme is where?

(2010/01/03 2:11), Larry Masinter wrote:
> http://tools.ietf.org/html/draft-hoffman-ftp-uri-04
> was intended to update the "ftp" URI scheme registration.
> 
> I don't remember exactly, but what I vaguely remember was
> that it was held up because the text *didn't* match
> common implementations.

I see, thank you for info.
I'll read it.

> Getting some attention paid to updating it would be
> helpful. Volunteers?

It is interesting.
I'm investigating "ftp" URI scheme to fix Ruby's uri/ftp lib.
I think, RFCs which didn't match common implementations
should be updated and match implementations.
(as cookie/http-state and its current work)

Anyway I'll feedback findings through it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 4 Jan 2010 19:12
Picon
Picon

When is percent-encoding required.

Draft-ellermann-news-nntp-uri-11.txt is currently going through AUTH48  
and, since Frank Ellermann seems not to have been heard from for more than  
a year, and cannot be contacted, I am getting the job of seeing what needs  
to be done (most notably changes necessitated by the AUTH48 changes in RFC  
5536).

I find the question of just what needs to be percent-emcoded is hard to  
deduce from RFC 3986. Clearly, anything in <gen-delims> MUST be  
percent-encoded except when used as delimiters, so that agents can divide  
a URI into scheme, authority, path, query, and fragment components even  
before they recognise that it is a news or nntp URI. But is it REQUIRED  
for the <sub-delims> if the particular scheme does not use any of them as  
delimiters? RFC 3986 seems to imply not, so I would expect that in
    news:foo <at> bar.!#$%&'*+/=?^`{|}.example
(yes, "bar.!#$%&'*+/=?^`{|}.example" is a valid <dot-atom-text> and hence  
can occur in a Message-ID) I would have to percent-encode the '#'. '/' and  
'?', but not the others. Frank seems to have taken the view that all  
<sub-delims> need to be encoded, though he does at one point permit '*' to  
appear unencoded (and it was indeed explicitly allowed in RFC 1738), which  
appears to be inconsistent wuth his stance elsewhere

And he also includes an example
    news://news.gmane.org/p0624081dc30b8699bf9b <at> %5B10.20.30.108%5D
where I would have thought he could have shown
    news://news.gmane.org/p0624081dc30b8699bf9b <at> [10.20.30.108]

So exactly what latitude does RFC 3986 permit in these situations?

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bob Aman | 4 Jan 2010 21:27
Picon
Gravatar

Re: When is percent-encoding required.

> I find the question of just what needs to be percent-emcoded is hard to
> deduce from RFC 3986. Clearly, anything in <gen-delims> MUST be
> percent-encoded except when used as delimiters, so that agents can divide a
> URI into scheme, authority, path, query, and fragment components even before
> they recognise that it is a news or nntp URI. But is it REQUIRED for the
> <sub-delims> if the particular scheme does not use any of them as
> delimiters? RFC 3986 seems to imply not, so I would expect that in
>   news:foo <at> bar.!#$%&'*+/=?^`{|}.example
> (yes, "bar.!#$%&'*+/=?^`{|}.example" is a valid <dot-atom-text> and hence
> can occur in a Message-ID) I would have to percent-encode the '#'. '/' and
> '?', but not the others. Frank seems to have taken the view that all
> <sub-delims> need to be encoded, though he does at one point permit '*' to
> appear unencoded (and it was indeed explicitly allowed in RFC 1738), which
> appears to be inconsistent wuth his stance elsewhere

For certain, you should percent-encode that "%" as well, but I'm
inclined to believe you should percent encode the "^`{|}" also.  I
think this would be the correct normalized form:
news:foo <at> bar.!%23$%25&'*+%2F=%3F%5E%60%7B%7C%7D.example  (I have
assumed that the intent was for that to be parsed as the path
component.)

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / " <at> "

However, I believe virtually all URI parsers will interpret
"news:foo <at> bar.!%23$%25&'*+%2F=%3F^`{|}.example" as intended.

-Bob Aman
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Anthony Pasquale Holsten | 4 Jan 2010 22:12
Gravatar

Re: When is percent-encoding required.

"Charles Lindsey" <chl <at> clerew.man.ac.uk> said:
> Draft-ellermann-news-nntp-uri-11.txt is currently going through AUTH48  
> and, since Frank Ellermann seems not to have been heard from for more 
> than  a year, and cannot be contacted, I am getting the job of seeing 
> what needs  to be done (most notably changes necessitated by the AUTH48 
> changes in RFC  5536).

Sorry to hear Ellerman hasn't turned up. I'm glad you're pushing forward.

> I find the question of just what needs to be percent-emcoded is hard to 
>  deduce from RFC 3986. Clearly, anything in <gen-delims> MUST be  
> percent-encoded except when used as delimiters, so that agents can 
> divide  a URI into scheme, authority, path, query, and fragment 
> components even  before they recognise that it is a news or nntp URI. 
> But is it REQUIRED  for the <sub-delims> if the particular scheme does 
> not use any of them as  delimiters? RFC 3986 seems to imply not, so I 
> would expect that in
>     news:foo <at> bar.!#$%&'*+/=?^`{|}.example
> (yes, "bar.!#$%&'*+/=?^`{|}.example" is a valid <dot-atom-text> and 
> hence  can occur in a Message-ID) I would have to percent-encode the 
> '#'. '/' and  '?', but not the others. Frank seems to have taken the 
> view that all  <sub-delims> need to be encoded, though he does at one 
> point permit '*' to  appear unencoded (and it was indeed explicitly 
> allowed in RFC 1738), which  appears to be inconsistent wuth his stance 
> elsewhere
> 
> And he also includes an example
>     news://news.gmane.org/p0624081dc30b8699bf9b <at> %5B10.20.30.108%5D
> where I would have thought he could have shown
>     news://news.gmane.org/p0624081dc30b8699bf9b <at> [10.20.30.108]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin J. Dürst | 5 Jan 2010 08:12
Picon
Gravatar

Re: When is percent-encoding required.

Hello Charles,

Bob and Joseph have said most that needs to be said. In summary, I don't 
think there's anything wrong with respect to escaping in Frank's draft. 
If you can point to anything specific, I'll have another look at it. 
(see below for details)

On 2010/01/05 3:12, Charles Lindsey wrote:
> Draft-ellermann-news-nntp-uri-11.txt is currently going through AUTH48
> and, since Frank Ellermann seems not to have been heard from for more
> than a year, and cannot be contacted, I am getting the job of seeing
> what needs to be done (most notably changes necessitated by the AUTH48
> changes in RFC 5536).
>
> I find the question of just what needs to be percent-emcoded is hard to
> deduce from RFC 3986. Clearly, anything in <gen-delims> MUST be
> percent-encoded except when used as delimiters, so that agents can
> divide a URI into scheme, authority, path, query, and fragment
> components even before they recognise that it is a news or nntp URI.

Yes indeed.

But
> is it REQUIRED for the <sub-delims> if the particular scheme does not
> use any of them as delimiters? RFC 3986 seems to imply not, so I would
> expect that in
> news:foo <at> bar.!#$%&'*+/=?^`{|}.example
> (yes, "bar.!#$%&'*+/=?^`{|}.example" is a valid <dot-atom-text> and
> hence can occur in a Message-ID) I would have to percent-encode the '#'.
> '/' and '?', but not the others.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 6 Jan 2010 18:33
Picon
Picon

Re: When is percent-encoding required.

On Tue, 05 Jan 2010 07:12:37 -0000, Martin J. Dürst
<duerst <at> it.aoyama.ac.jp> wrote:

> Hello Charles,
>
> Bob and Joseph have said most that needs to be said. In summary, I don't  
> think there's anything wrong with respect to escaping in Frank's draft.  
> If you can point to anything specific, I'll have another look at it.  
> (see below for details)
>
> On 2010/01/05 3:12, Charles Lindsey wrote:

>> is it REQUIRED for the <sub-delims> if the particular scheme does not
>> use any of them as delimiters? RFC 3986 seems to imply not, so I would
>> expect that in
>> news:foo <at> bar.!#$%&'*+/=?^`{|}.example
>> (yes, "bar.!#$%&'*+/=?^`{|}.example" is a valid <dot-atom-text> and
>> hence can occur in a Message-ID) I would have to percent-encode the '#'.
>> '/' and '?', but not the others.
>
> Sorry, but you also have to encode characters that are not allowed in  
> URIs at all, i.e. '{', '}', '`', "'", "^", and "|". Bob mentioned these,  
> but wasn't very definitive and didn't give a reason. And of course, as  
> Bob mentioned, "%" has to be escaped.

Ah! I had not spotted that there existed characters that were neither
<reserved> nor <unreserved>. Does RFC 3986 have anything to say about
them, or does silence imply that encoding is needed?

Anyway, it seems the list of things needing percent encoding in that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Wilde | 6 Jan 2010 19:30
Picon
Favicon
Gravatar

non-HTTP URIs in HTTP requests

hello.

i have a technical question about HTTP and URIs. my use case is that i 
am considering to use HTTP for the resolution of non-HTTP URIs, so that 
for example (this is my use case) a geo:37.0625,-95.677068 URI could be 
"resolved" via HTTP. regardless of the actual process (what "resolution" 
returns in the response), i am currently just trying to find out whether 
it would be legal to send a HTTP request like this:

GET geo:37.0625,-95.677068 HTTP/1.1

it seems to me that RFC 2616 does not prohibit such a use, but i am sure 
that a lot of people will dislike it for various reasons. however, 
currently i am just interested to figure out whether it's legal, and i 
think it is (not the geo: per se, which is not yet a standard, but the 
fact that there is a non-HTTP URI in the request). if i am mistaken, 
feedback would be greatly appreciated.

thanks,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret <at> berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Permalink | Reply | 19 comments |
headers
Jan Algermissen | 6 Jan 2010 21:29
Picon

Re: non-HTTP URIs in HTTP requests

Erik,

basically, I think what matters most is whether the request method is  
defined for the geo: protocol.

I do not think that http forbids the use of non http URIs because the  
client component is supposed to select the correct connector based on  
the protocol. So, a geo: URI would normally never end up in an HTTP  
request.

OTH, HTTP 1.1 requires the Host header field and if that does not  
match the host of the URI you end up with a proxy request anyway. So  
the question would technically be how the target host of the first  
request hop (as given in the Host header) deals with the geo: URI. If  
you write a proxy to do some sort of resolution of the geo: URI I  
think that should work.

HTH,

Jan

On Jan 6, 2010, at 7:30 PM, Erik Wilde wrote:

> hello.
>
> i have a technical question about HTTP and URIs. my use case is that  
> i am considering to use HTTP for the resolution of non-HTTP URIs, so  
> that for example (this is my use case) a geo:37.0625,-95.677068 URI  
> could be "resolved" via HTTP. regardless of the actual process (what  
> "resolution" returns in the response), i am currently just trying to
(Continue reading)

Permalink | Reply | 13 comments |
headers
John Cowan | 6 Jan 2010 22:01

Re: non-HTTP URIs in HTTP requests

Erik Wilde scripsit:

> i have a technical question about HTTP and URIs. my use case is that i 
> am considering to use HTTP for the resolution of non-HTTP URIs, so that 
> for example (this is my use case) a geo:37.0625,-95.677068 URI could be 
> "resolved" via HTTP. regardless of the actual process (what "resolution" 
> returns in the response), i am currently just trying to find out whether 
> it would be legal to send a HTTP request like this:
> 
> GET geo:37.0625,-95.677068 HTTP/1.1

That is legal:  RFC 2616 (HTTP/1.1), Section 5.1.2, says that the
Request-URI may be an absoluteURI, which "geo:37.0625,-95.677068" is.
The relevant text:

   The absoluteURI form is REQUIRED when the request is being made to a
   proxy. The proxy is requested to forward the request or service it
   from a valid cache, and return the response. Note that the proxy MAY
   forward the request on to another proxy or directly to the server
   specified by the absoluteURI. In order to avoid request loops, a
   proxy MUST be able to recognize all of its server names, including
   any aliases, local variations, and the numeric IP address. An example
   Request-Line would be:

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

   To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roy T. Fielding | 6 Jan 2010 22:11
Favicon
Gravatar

Re: non-HTTP URIs in HTTP requests

On Jan 6, 2010, at 10:30 AM, Erik Wilde wrote:

> i have a technical question about HTTP and URIs. my use case is that i am considering to use HTTP for the
resolution of non-HTTP URIs, so that for example (this is my use case) a geo:37.0625,-95.677068 URI could
be "resolved" via HTTP. regardless of the actual process (what "resolution" returns in the response), i
am currently just trying to find out whether it would be legal to send a HTTP request like this:
> 
> GET geo:37.0625,-95.677068 HTTP/1.1

Yes, that is a normal proxy request, assuming the proxy has been
configured to resolve geo addresses.  What would the response be?

Host is only required when the URI contains an authority component.

....Roy
Permalink | Reply | 2 comments |

Gmane