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

From: "Christopher R. Hertel" <[email-masked]>
Date: Tue, 02 Jan 2007 10:46:13 -0600

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/     -)-----   [email-masked]
OnLineBook -- http://ubiqx.org/cifs/    -)-----   [email-masked]

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

---

From: Claus Färber <[email-masked]>
Date: Thu, 11 Jan 2007 11:41:13 +0100

> 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).
"smb://" also does not fit into the generic SMB syntax, "smb:" is not an 
alternative as it is a relative URL to the current document.

Collisions between DNS and NETBIOS names should be avoided, too.

Claus

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Thu, 11 Jan 2007 13:01:40 -0600

Claus,

You've identified some of the biggest compromises that needed to be made to
get the SMB URI scheme to work.  SMB is an old protocol, and there are a lot
of conventions (and ingrained expectations) that need (to some extent) to be
accommodated.

[Aside: I submitted draft v12 but had to get it in by the deadline and
        didn't have time to include all of the recommendations I've
        received so far.  I'll keep working on them and add the new
        boilerplate that Frank pointed out.]

> not "smb://bar" ("//bar" would be allowed).

The relationship between workgroups and servers is not properly
hierarchical.  To include support for both (which is something all of the
implementations do) there has to be some overloading.  The goal of the draft
is to specify a standard way to make that overloading work.

One way around the problem you've identified is to consider workgroups and
servers to be at the same level in the hierarchy.  That's what we've done
syntactically.  The result of:

  smb://<workgroup>/

is a list of servers that are members of the workgroup.

There is, however, a logical hierarchy that exists.  That is:  servers can
be members of workgroups.  As a result, it has been suggested that the URI
scheme should take the form.

  smb://<workgroup>/<server>/

but that format was rejected because:

* The workgroup system is a convention.  Technically, servers do not need
  to be part of a workgroup.  Under so-called "naked" transport (non-NBT)
  the workgroup scheme goes away so including the workgroup in the path
  won't work in that case.

* Users are currently accustomed to the ability to access servers directly,
  without having to specify the workgroup.

In the current revision of the draft, I outline one suggested behavior for
user agents.  That behavior is to make the lateral (where possible) move
from server to workgroup when moving upward in the hierarchy.

It's messy, but here's the idea:

- Syntactically, adding ".." to smb://<server>/ should give smb:// (more on
  smb:// in a moment).

- Semantically, however, an NBT-based server will likely be a member of a
  workgroup.  In that case, a user agent *may* choose to make the lateral
  move and display the list of servers in the workgroup.  That is:

  smb://<server>/ + ".." ==> smb://<workgroup>/

  where <server> happens to be a member of <workgroup>.

Yeah that's ugly, but it is what happens when browsing the Network
Neighborhood.  When you are viewing the shares available from a server and
go "up", you get the workgroup member list (the servers in the workgroup).

Because the most common implementation behaves this way (even though it
doesn't support this URI scheme), it is likely that other implementations
will follow suit.

On the other hand, it's not clear how similar behavior would be implemented
in a non-NBT environment (the subject of another recent e'mail discussion)
so this is a point which needed to be raised and reconsidered.

> alternative as it is a relative URL to the current document.

Yep, but this has been discussed a few times.  It's the only way to access
the list of workgroups (since there's no "name" at the top of the hierarchy).

...and yes, support for workgroup browsing needs to be included.  It was
included in the very first implementations of this scheme mostly because it
mimics the behavior of the Network Neighborhood.  All current
implementations of the SMB URI (of which I am aware) support this sytnax.

> Collisions between DNS and NETBIOS names should be avoided, too.

Absolutely, and it's an argument I've lost a thousand times.

The default on Windows and Samba systems is to use the hostname as the base
name when forming NetBIOS names.  So my old machine ruby.nts.umn.edu formed
NetBIOS names as "RUBY" + <padding> + <suffix byte>.  Using common NetBIOS
name notation, the Server Service was RUBY<20> and the Browser Election
Listener was RUBY<1E>.

The thing is, there is no real reason (from the protocol perspective) that
the above mapping needs to be enforced.  It's a convenience only.  NetBIOS
names have completely different *meaning*.  A NetBIOS name represents a
service (like a port under TCP or UDP), while a DNS name resolves to the IP
address of an interface.

From that perspective, the whole business of mapping DNS names to NetBIOS
services really doesn't make any sense.   ...but it's common practice.  A
kludge that has become a tradition that won't be broken.  Sigh.

I've spent a lot of time with this protocol suite.  It's quirky at best.

Again, you've identified issues that are important.  Some of them have been
discussed in detail previously but I can go over them again.

Thanks!

Chris -)-----

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Jan 2007 20:05:28 +0100

> 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

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Thu, 11 Jan 2007 13:20:04 -0600

Frank Ellermann wrote:
> as for file / ftp / http.

For the workgroup system to be supported by the scheme there must be a
mechanism for listing available workgroups.  It's a sort of boot-strap
process since nothing is known about the local environment until a few
queries are performed behind the scenes.  There's no "name" associated with
"all of the available workgroups", which is why we added the (admittedly
unusual) "smb://" to the top of the hierarchy.

So, yeah... it's an implicit root of sorts.

The traversal between server service and browser service servers is
definitely something that could use some review.  If the scheme is going to
support workgroups at all, however, then I think we need to maintain the
"smb://" semantics.  It's something that has come up time and again and the
usual end-result of the discussion is "Ugh.  Yeah, I guess that's the best
way to make it work."  I've said that myself more than once.  :)

Thanks!

Chris -)-----

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Jan 2007 23:09:25 +0100

Christopher R. Hertel wrote:

> If the scheme is going to support workgroups at all, however, then
> I think we need to maintain the "smb://" semantics.

Excluding the special case smb:// (I try to tackle that below) what
you have about absolute URLs should work.  One problem pointed out
by Claus was for relative URLs using /.. segments:  You can't invent
special rules for ../bar at smb://foo/ resulting in  smb://bar/, the
general rules in RFC 3986 don't allow this.

The reason is that all UAs will handle "." and ".." as specified in
chapter 5.2 of RFC 3986, no matter what the actual scheme is, smb or
ftp or anything else using path-segments separated by slashes.

And with that algorithm there's no relative way from smb://foo/ to
smb://bar/ because "//foo" is parsed as "authority".  I think you're
forced to accept this, here the "U" (uniform) in "URI" beats scheme-
specific ideas.

For the smb: vs. smb:// issue I can't tell what's better, the general
syntax apparently allows an "empty authority" as in smb://  

   URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

Remove query and fragment, there's no "?" and no "#" in "smb://"
Identify "smb" as scheme, ":" as separator, that leaves "//"

   hier-part     = "//" authority path-abempty

The only way to get "//" at this position, so now we need an empty
authority and an empty path-abempty to finish this.

   path-abempty  = *( "/" segment )

path-abempty can be completely empty (zero segments).

   authority     = [ userinfo "@" ] host [ ":" port ]

userinfo and host are only optional, now we need an empty host (of
course this is okay as in "file:///", but I check the host anyway):

   host          = IP-literal / IPv4address / reg-name

No chance with the literals, they're never empty.  Therefore we need
an empty reg-name:

   reg-name      = *( unreserved / pct-encoded / sub-delims )

Bingo, zero or more characters, we pick zero.  "smb://" is allowed,
syntactically.  But Claus only wrote that '"smb://" also does not
fit into the generic SMB syntax', that's not the generic URI syntax.

Frank

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Thu, 11 Jan 2007 18:09:42 -0600

Lisa Dusseault wrote:
> 
> 
> I consider this kind of relative reference to be difficult and quite
> possibly harmful in protocols.

Please keep in mind that the protocols involved have existed for a long
time.  The best I can do is provide the most sensible URI scheme.

> It's fine to use in a user-interface as
> a shortcut, but there had better be a good reason why the URL isn't
> canonicalized so as not to contain ".." before appearing over the
> wire.   Even relative references that don't use ".." -- e.g.  absolute
> paths -- may be difficult.

The ".." would not appear over the wire.  It's a decision the User Agent
would make.

> If the scope is limited to use within one stored document and that
> document's base URL (e.g. a Web page), relative references work well
> enough and solve the problem of moving around hierarchies of documents
> without changing all the references within.  Part of the reason that
> works is that the whole document is used entire, so some kind of
> relative reference consistency is possible.  I don't see that's the case
> for this kind of URI yet, or what use case relative references would
> solve for this type of URI.

SMB is a filesharing protocol so the content of any stored document is not
really relevant.  Many of the files referenced won't be parsable by the User
Agent.

> Some of the problems found:
>  - Possible to lose the "base URL" or disagree about what it is or have
> several possible referents (see http://w3future.com/weblog/2005/08/ for
> an example in Atom)
>  - URI matching use cases difficult or broken
>  - poor implementation track record outside of HTML use

I think we're off track here.  I've done, it seems, a poor job of explaining
how the underlying protocol already works and how this scheme is intended to
map to that existing set of semantics.

I'm hoping one of my earlier messages will clear some of this up, but it's
an important point so please keep the discussion going.  I appreciate it!

Chris -)-----

---

From: Claus Färber <[email-masked]>
Date: Sat, 13 Jan 2007 18:24:46 +0100

Frank Ellermann wrote:
> Bingo, zero or more characters, we pick zero. 

That was a change from RFC 2396 that I seem to have missed.

But the spec also implies that an empty "host" part is a default host 
and that a non-empty "reg-name" should be interpreted by the operating 
system.

Browsing is different from accesing the top-level directory of any host, 
so you just can't insert an default value for an empty "reg-name" and 
try to access that.

However, the same is true for browsing workgroups. Browsing and file 
access are actually related, but different protocols. Maybe it would be 
the best to have a different URI scheme for browsing:

	smb-browse:			# whole network
	smb-browse:WORKGROUP		# workgroup

As a side note: This would also allow implementing it with different 
protocol handlers in operating systems and GUI frameworks; a "smb" 
handler does not need about browsing and a "smb-browser" does not need 
to implement file access.

While I'm at it: There should also be different schemes for SMB over 
NetBIOS ("smb", default port 139) and CIFS/SMB over raw TCP ("cifs", 
default port 445).

> But Claus only wrote that '"smb://" also does not

I actually did mean 'generic URI syntax'. Sorry.

Claus

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 11 Jan 2007 14:25:48 -0800

I consider this kind of relative reference to be difficult and quite  
possibly harmful in protocols.  It's fine to use in a user-interface  
as a shortcut, but there had better be a good reason why the URL  
isn't canonicalized so as not to contain ".." before appearing over  
the wire.   Even relative references that don't use ".." -- e.g.   
absolute paths -- may be difficult.

If the scope is limited to use within one stored document and that  
document's base URL (e.g. a Web page), relative references work well  
enough and solve the problem of moving around hierarchies of  
documents without changing all the references within.  Part of the  
reason that works is that the whole document is used entire, so some  
kind of relative reference consistency is possible.  I don't see  
that's the case for this kind of URI yet, or what use case relative  
references would solve for this type of URI.

Some of the problems found:
  - Possible to lose the "base URL" or disagree about what it is or  
have several possible referents (see http://w3future.com/weblog/ 
2005/08/ for an example in Atom)
  - URI matching use cases difficult or broken
  - poor implementation track record outside of HTML use

Lisa

On Jan 11, 2007, at 2:41 AM, Claus Färber wrote:

> For example, "smb://foo" + "../bar" must resolve to "smb://foo/../ 
> bar", not "smb://bar" ("//bar" would be allowed).
> "smb://" also does not fit into the generic SMB syntax, "smb:" is  
> not an alternative as it is a relative URL to the current document.
>

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 11 Jan 2007 14:25:48 -0800

Lisa

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Tue, 16 Jan 2007 11:32:25 -0600

An update...

First, thanks to all who have been sending me comments both on and off the
mailing lists.  I am doing my best to process them.  I have a good
understanding of the protocols underlying the SMB URI scheme, but the
process of specifying that scheme--and to a greater extent the arcana of
trying to get a workable draft into the IETF--are testing me.

I have submitted draft #12, but it reflects only those few changes that I
could make before the deadline.  On the positive side, it means I have a bit
of time to get the draft "right".

I think that the top issue raised has to do with the workings of Workgroup
browsing using the SMB URI scheme.  My plan is to start by addressing those
issues.  I did send out a description of the workings of Workgroup browsing.
 My hope is that my description will clarify (without defending) what it is
that the draft is currently trying to accomplish.

Chris -)-----

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 16 Jan 2007 19:03:50 +0100

Christopher R. Hertel wrote:

> to a greater extent the arcana of trying to get a workable draft
> into the IETF--are testing me.

The formal hurdles aren't supposed to be a major obstacle.  For your
draft it boils down to "validate the ABNF", "use the 'idnits' tool"
<http://tools.ietf.org/tools/idnits/>, "read the RFC about new URI
scheme registrations" (RFC 4395), and find a successful registration
based on 4395 as example - 4395 is relatively new.

And of course "follow 3986 rules", the ../foo issue.  But that's no
arcane IETF procedure, that's an ordinary bug found by Claus.

Frank

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Jan 2007 21:00:26 +0100

Christopher R. Hertel schrieb:
> ...

Just for the record: it's not really a deadline. If an ID expires, it 
only disappears from the official site. It's still archived, available 
from other places (such as tools.ietf.org), and can be updated later on.

Best regards, Julian