W3C home > Mailing lists > Public > uri@w3.org > August 2003

RE: [Uri-review] SMB URL v05.

From: Martin Duerst <duerst@w3.org>
Date: Mon, 11 Aug 2003 16:22:41 -0400
Message-Id: <4.2.0.58.J.20030811161214.02e6edf0@localhost>
To: "McDonald, Ira" <imcdonald@sharplabs.com>, "'Christopher R. Hertel'" <crh@ubiqx.mn.org>
Cc: uri-review@ietf.org, uri@w3.org

Hello Ira,

[I have copied the uri list.]
Is it possible to construct service URIs from arbitrary other
URIs, or are there some restrictions?

Please note that RFC 2396 does not restrict the syntax after
// to be [ [ userinfo "@" ] hostport ]. In particular we have
(from http://www.ietf.org/rfc/rfc2396.txt, App A. Collected BNF for URI):

net_path      = "//" authority [ abs_path ]
authority     = server | reg_name
reg_name      = 1*( unreserved | escaped | "$" | "," |
                           ";" | ":" | "@" | "&" | "=" | "+" )
server        = [ [ userinfo "@" ] hostport ]

This leaves open the "regname" part, which is arbitrary.
This means that if the 'service:' uri allows to just plug
in arbitrary URIs, it would be against the current RFC 2396
syntax. However, it would be okay with the new, proposed
RFC 2396bis syntax.

Also, are you saying that the /ipx/ and /at/ conventions
should be general conventions for URIs? Or are they just
conventions within the 'service:' URI Scheme?

Please note that the change from RFC 2396 to RFC 2396bis
does not prohibit the use of  things such as NetWare or
Appletalk as long as they don't appear after //, which
seems to be okay for the 'service:' URI, but not for
SMB.

Regards,    Martin.

At 12:30 03/08/11 -0700, McDonald, Ira wrote:
>Hi Martin,
>
>I'm concerned.  SLP "service:" URL (RFC 2609) has a basic
>dependence on the differentiation that "scheme://..." is
>a DNS-based URL and "scheme:/ipx/..." is a NetWare URL
>(Appletalk is also supported).
>
>There is a heck of a lot of deployed SLP software that uses
>non-DNS URLs regularly.
>
>Cheers,
>- Ira McDonald
>   High North Inc
>
>[excerpts from the ABNF in RFC 2609]
>
>service: URL    =   "service:" service-type ":" sap
>service-type    =   abstract-type ":" url-scheme / concrete-type
>abstract-type   =   type-name [ "." naming-auth ]
>concrete-type   =   protocol [ "." naming-auth ]
>
>sap             =   site [url-part]
>site            =   ipsite / atsite / ipxsite
>ipsite          =   "//" [ [ user "@" ] hostport ]
>ipxsite         =   "/ipx/" ipx-net ":" ipx-node ":" ipx-socket
>atsite          =   "/at/" at-object ":" at-type "" at-zone
>
>
>-----Original Message-----
>From: Christopher R. Hertel [mailto:crh@ubiqx.mn.org]
>Sent: Monday, August 11, 2003 2:44 PM
>To: Martin Duerst
>Cc: Christopher R. Hertel; uri-review@ietf.org
>Subject: Re: [Uri-review] SMB URL v05.
>
>
>On Mon, Aug 11, 2003 at 10:30:15AM -0400, Martin Duerst wrote:
> > Hello Christopher,
> >
> > Have you checked your syntax for compatibility with the RFC2396bis
> > update (draft-fielding-uri-rfc2396bis-03)?
> >
> > In particular, it looks like you are allowing non-DNS stuff in
> > the authority (hostname) part. RDF2396bis does no longer allow
> > this.
>
>There's no option on that.  SMB can and does use RFC1001/1002 NBT naming
>for service access.  Any URL for SMB must support this.  It's just part of
>the protocol.
>
>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
>
>_______________________________________________
>Uri-review mailing list
>Uri-review@ietf.org
>https://www1.ietf.org/mailman/listinfo/uri-review
>
>_______________________________________________
>Uri-review mailing list
>Uri-review@ietf.org
>https://www1.ietf.org/mailman/listinfo/uri-review
Received on Monday, 11 August 2003 16:44:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:32 GMT