Re: URI Scheme that needs help.

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

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
http://rtg.ietf.org/~fenner/abnf.cgi

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. 

Frank

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