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

Frank Ellermann wrote:
> 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.

That's good news.  Thanks.

> 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 whole workgroup thing is so confusing I had to write several sections of
a book just to explain it.  I've been working with various implementations
of the SMB URI for a while.  Some get it right, others keep getting closer,
so I think I've gotten them onto the right track.

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

Yes and no.  If the two servers are in the same scope then they would
generate a name conflict and one of the systems would fail to register.

The reason workgroup name vs. server service name conflict *can* occur is
that those names are registered with different suffix bytes so they don't
actually conflict.

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

This is something I probably need to address better.  Each server can be a
member of a single workgroup, but it's simply a question of membership.
There's really no hierarchical relationship.  The SMB URI imposes a
pseudo-hierarchical relationship for convenience only.

The workgroup thing is an add-on.  It would be very easy to modify (for
example) Samba so that it did not announce its workgroup membership, which
would mean that it wasn't part of a workgroup at all.

So if I have a server Q in workgroup A, and another server R in B, then...

  smb://A/  + ../R/  ==> smb://R/

...which is still valid, even though R isn't a member of A.

> 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

Okay.  This is where I will probably need some guidance.

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

I have had trouble with this type of change in the past so I really
appreciate the heads up.

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

I believe Windows systems do that, so I will have to find a Windows system
and check it out.

I have some other updates that were sent to me.  My plan at this point is to
create an updated draft in time for the deadline and then work through any
of the tasks you've outlined that I was not able to accomplish in time for
that deadline.

I'm now getting a lot of help on this, and I appreciate it.  I'm really
quite a noob at this IETF Draft stuff.

Thanks!

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/     -)-----   crh@ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh@ubiqx.org

Received on Tuesday, 2 January 2007 16:46:39 UTC