W3C home > Mailing lists > Public > uri@w3.org > December 2006

Re: URI Scheme that needs help.

From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sun, 31 Dec 2006 18:20:53 +0100
To: uri@w3.org
Message-ID: <4597F175.6F59@xyzzy.claranet.de>
Cc: uri-review@ietf.org

Christopher R. Hertel wrote:

> I could really use some help rewriting the draft
> - to look more like a *real* IETF document,
> - to fill in some of the gaps that are still there,
> - to ensure compliance with existing RFCs.

Just for fun I read pages 1..8 and 15..18, and found nothing too 

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.

You could add a more interesting example, where a server name exists
in two groups, say group A with servers X and Y, and group B with
servers Y and Z.  After doing something with smb://X/ I'd expect
../Y to be the Y in group A, not the Y in group B, is that correct ?

You already have an example for ../Y after accessing smb://A/.  What
about ../Z ?  I'd expect it to be invalid, because there's no Z in A.
Maybe you could extend your example in this direction.

You need to split the references into "normative" and "informative",
and you've to add "IANA considerations" (asking them to add smb and
cifs to their URI registry).  If you haven't done it yet run the I-D
through http://tools.ietf.org/tools/idnits/ and check your ABNF with

At some point in time (IIRC February) you'll need the new boilerplate,
in essence that's s/ISOC/IETF Trust/.  The IETF Secretary will tell 
you when they don't accept the old boilerplate anymore.  

If there are UAs trying to interpret file://s/p like smb://s/p please 
mention it.  "file" is one of the old schemes still waiting for its
3986-update, and doing this with a reference to your (future) RFC
could simplify this task. 

Received on Sunday, 31 December 2006 17:25:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:10 UTC