Subject: [Uri-review] URI Scheme that needs help.

From: "Christopher R. Hertel" <[email-masked]>
Date: Sat, 30 Dec 2006 15:30:03 -0600

I've been working on an Internet Draft for the SMB URI scheme for years now,
but the draft really needs some help.  Version 11 (!) of the draft is set to
expire in a week.

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.

I have been the only author on this document and I'm not happy with that.
I could really use some help.

The SMB URI is now widely implemented based on these drafts and on a
description I provided online:  http://www.ubiqx.org/cifs/Appendix-D.html

Software that supports the SMB URI scheme includes:
- Mac OS X
- The Firefox Browser (under Linux & possibly others, but not Windows)
- KDE's Konqueror browser
- jCIFS (Java SMB/CIFS client)
- Samba's libsmbclient (incomplete support)
- probably several others I don't even know about.

I really would like to see a "real" specification published.  Right now the
current draft needs some updating so that I can re-submit it but I would
like to get it ready for prime-time.

The current draft is in the usual place:

  http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-11.txt

My fingers are crossed.

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   [email-masked]
OnLineBook -- http://ubiqx.org/cifs/    -)-----   [email-masked]

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 31 Dec 2006 18:20:53 +0100

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