Subject: [Uri-review] Query section persistence over relative URIs.

From: "Christopher R. Hertel" <[email-masked]>
Date: Tue, 18 Nov 2003 15:29:03 -0600

Hi folks.

Following the informal URI meeting at the 58th (thanks again to everyone
who attended for all of their help) I'm working on an update to the SMB
URL draft that is currently submitted.  I don't anticipate changing
anything, but I will be clarifying things a bit.  Along those lines...

=- Should it be "SMB URI" instead of "SMB URL"?  I'm still not clear on 
   the distinction so I'll go along with whatever.

=- My main question:  Is it reasonable to require that the query section 
   be persistent following a relative URI operation?  For example:

        I enter: smb://fooburp/share/path?NBNS=192.168.101.1
   Then I enter: ../alt-path/file.txt
       Do I get: smb://fooburp/share/alt-path/file.txt
             or: smb://fooburp/share/alt-path/file.txt?NBNS=192.168.101.1

   My question, really, is whether the behavior is already defined.  If
   so, please help me out by pointing me to the right part of the docs.
   If not, ...well, I doubt that's the case so I've obviously missed it.

   Having thought about this a bit, it really won't matter much which way
   things go, I just need to know so that I can spell things out in the
   draft.

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: Martin Duerst <[email-masked]>
Date: Tue, 18 Nov 2003 19:50:45 -0500

Please look at RFC 2396, which describes exactly what happens
with query parts in the case of relative URI resolution.
For the newest version of the ongoing update of RFC 2396,
please see http://gbiv.com/protocols/uri/rev-2002/.

I'm not sure what you mean below by 'then I enter'.
Do you mean that you enter a relative URI e.g. in the address
bar of a browser? I'm not at all sure something like this
has ever worked. So I guess it must be something else.

Regards,    Martin.

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Tue, 18 Nov 2003 20:05:58 -0600

> please see http://gbiv.com/protocols/uri/rev-2002/.

Thanks, Martin.

I've looked through 2396 and not found what I'm looking for but that is
probably because I'm not looking in the right place or with the right idea
of what to look for.

I did notice this in 2396:

  3.4. Query Component

   The query component is a string of information to be interpreted by
   the resource.

In the case of the SMB URI, the query component must be interpreted by the
client implementation underlying the user agent.  The NBT layer
(RFC1001/1002) requires context, so we needed a mechanism for supplying that
context in the URI string.  The query component seemed a good choice.

The sentence above brings up a new question, however:  Is "the resource"
defined to be the remote resource identified by the URI string or is it okay
to have the query string interpreted by the client?

> has ever worked. So I guess it must be something else.

In the jCIFS project we have a couple of test tools that we use.  They allow
you to enter an SMB URI string which causes the tool to open an SMB
connection to the location given.  Assuming the connection is a success, you
can traverse the SMB hierarchy by entering relative URIs.

...so, your first interpretation is correct.

I know that's not normal web browser behavior, but conceptually that's what
happens (in my twisted little mind, anyway) when you select an href that
indicates a relative reference.

I know I'm not getting all of the URI terminology or syntax quite right in
some of these messages, but my background is in SMB not in URI composition. 
That's why I'm asking so many questions.  I need help to get this stuff
right, and I really appreciate the comments and guidance.

Thanks again!

Chris -)-----

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Tue, 18 Nov 2003 20:29:24 -0600

> please see http://gbiv.com/protocols/uri/rev-2002/.

Ahh...  There it is, in section 5.2 of 2396:

  The base URI's query component is not used by the resolution algorithm
  and may be discarded.

The keyword there, though, is "may".

I'm looking through draft-fielding-uri-rfc2396bis-03.html to see if there is
any further clarification, and it seems to suggest that the query string is
not included in the recomposed reference.  I don't think that this is
explicit, however.

The more I think about it, though, the more I think that's okay.

Sort of...

Let's say I start with:

  smb://foobelch/share/dir0/dir1/?NBNS=10.2.27.1;CALLED=CLIANT

...and then I have the relative URI:

  ?NBNS=192.168.2.1

This poses a few interesting problems:

  1) The name "foobelch" may resolve differently using a different NBNS.
     I solve this by saying "heck with that, it's a relative URI so the
     meaning of the authority part has already been determined".

     Well, sort of.  If I start with "smb://foobelch/?NBNS=10.2.27.1" and
     then apply "./?NBNS=192.168.2.1" that could be interpreted as meaning
     that the name "foobelch" needs to be re-resolved in a separate context.
     Urg.

  2) According to draft-fielding-uri-rfc2396bis-03 in sections 5.4 and 5.4.1
     the new query string would completely replace the old one, so the
     "CALLED=CLIANT" part of the context would be lost.

     I can solve this by stating that NetBIOS context remains the same upon
     application of a relative URI *unless* the relative reference
     specifically overrides a context value.

Other than the caveat in #1 above, how does that sound?

Chris -)-----