- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Thu, 11 Jan 2007 20:05:28 +0100
- To: uri@w3.org
- Cc: uri-review@ietf.org
Claus Färber wrote:
>> The concept of a workgroup context wrt to relative URLs is of course
>> odd, but your description makes it clear. Or I think it does.
> The hierarchy structure is not compliant with RFC 3986.
> For example, "smb://foo" + "../bar" must resolve to "smb://foo/../bar",
> not "smb://bar" ("//bar" would be allowed).
Apparently the author wants something like this for relative URLs:
An smb://foo/ URI is treated like
implicit-smb://known-working-group/foo The .../bar gets you to
implicit-smb://known-working-group/foo/../bar resulting in
implicit-smb://known-working-group/bar, and that's the same as
smb://bar/
That's how I understood his I-D.
Of course for schemes like file:, ftp:, and http: relative URLs
don't work as proposed for smb:, if you're at say ftp://example.com
then ../example.org won't result in ftp://example.org.
The smb: draft apparently tries to introduce an implicit root above
"foo" in smb://foo for its ../bar magic. The fastest way to fix
this oddity could be if the author temporarily removes anything
about relative URLs from his draft until the rest is clear, and
adds it again afterwards sticking to the normal RFC 3986 processing
as for file / ftp / http.
Frank
Received on Thursday, 11 January 2007 19:07:17 UTC