[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KURL bugs: defending RFC 1738
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-06-18 15:57:45
[Download RAW message or body]

Hello,

I was not going to say anything regarding this issue, since it has been
discussed in detail before in this list, but since you insist KURL breaks the
1738 spec. I will say a few things ( well more than a few things ) ....
 
On Fri, 18 Jun 1999, Oleg Noskov wrote:
[snipped]
> OK, I suggest you to follow this hyperlink and read it again:
> http://gatsby.tafe.tas.edu.au/CIE/RFC/1738/30.htm

Well, I have read this spec inside out ( might be sickening to some folks to
read RFC's ), but I have done it just the same ...

> UNC names are part of life. You cannot simply declare it to be Microsoft
> bullshit.

Well, it is/was a MS-proprietary protocol, which by the way works great in their
own platform.  Am I wrong here ???!!  And we all know why everyone else
has to live with it.

> URLs are widely used in communications. There's no such things as
>"Windows-specific" URLs and "UNIX-specific" URLs. All URLs are meant to be
> used across platforms.

Not true. I am afraid you are basing this either on the scheme specific
sections of RFC 1738 or the ubiquity of URL's.  URL's are designed to allow
you to access resources in a uniform manner.  You can have URL's that are based
on the "Common Internet Scheme Syntax", these are designated by having a "//"
preceded the scheme-specific-part of the protocol.  However, you can also create
URL's that are used for your own internal purpose.  Why you say? Perhaps you
might want to convert this to an Internet based scheme sometime in the future or
you just like the uniformity that URL's provide.  Hence, in order to accomplish
this all you have to do is follow section 2 of RFC 1738 which shows the general
syntax for URL's as <scheme>:<scheme-specific-part>.  This is from section 2.1

Now having said this, if KURL does not return the host name appropriately for
the "file:" protocol or that it does not follow the pattern in section 3.10,
all that tells you is that the implementation does not follow the Common
Internet Syntax.  THIS DOES NOT MEAN THAT IT IS NOT BASED ON
STANDARDS or argueably that it is a bug.  In fact, I am willing to bet ( since
I did not design it ) that the file protocol in KDE 1.x was designed for
accessing local file resources only and not files over the Internet. Thus, it is
correct in specifying the protocol as "file:/" and not "file://". Otherwise, it
would have been an incorrect implementation ....

> Today, people freely embed references to the UNC names in email messages and
> use URLs pointing to UNC resources in their intranet web pages. You cannot play
> with the standard and invent new proprietary schemes like "smb:" if you want
> your URLs to be understandable on other platforms.

What is proprietary about "smb:" ?? You mean not widely used or adapted right.
Something cannot be proprietary if it follows the standard specification.  What
you are saying here is that all URL's that are allowed can only be the ones
described in scheme-specific part of RFC 1738.  I don't think you really believe
this.  If you do, you have not read "Section 2 General URL Syntax".  In fact,
if the only "standard" protocols allowed were the ones explicitly mentioned in
RFC 1738, the specification itself will be outdated quickly.  Please look at the
whole Section 2 of this specification and not just the scheme-specific parts.

> It is too late to change anything in this regard already. There are millions
> and millions of applications all over the world which treat UNC names and
> their URLs just the way you don't seem to like. Just the way KURL class
> doesn't handle properly.
> UNC files have dual nature. They have a hostname inside, so the form
> file://machinename/sharename/foldername/.../filename is perfectly legal.
No argument here.  You are right. This is a perfectly legal URL per section
3.10 of RFC 1738.

> On the other hand, they can be just like normal local files, and many
> applications prefer to consider them to belong to the local host. Hence,
> file://localhost/\\machinename\sharename\foldername..\filename

Absolutely NOT !!!!!  Please read the "Unsafe" characters section of RFC 1738. 
If you to have "\" in the URL, you first have to encode it !!  Here is an
excerpt from RFC 1738 just in case ...

"Other characters are unsafe because gateways
and other transport agents are known to sometimes
modify such characters. These characters are
"{", "}", "|", "\", "^", "~", "[", "]", and "`".    

All unsafe characters must always be encoded within
a URL. For example, the character "#" must be encoded
within URLs even in systems that do not normally deal with
fragment or anchor identifiers, so that if the URL is copied
into another system that does use them, it will not be necessary
to change the URL encoding."

Moreover, please explain to me how average joe or jane will remember let alone
type type those many confusing slashes ???  See the advantage of having the
"smb://" protocol ? It is similar to all the other protocols people use daily
which make it much easier to remember or to teach.  In fact, in a previous
discussion on this list about the smb: protocol, we decided that we can
easily allow the user to type smb shares as they do now in windows (
\\machinename\sharename ) and then we can easily convert it internally to the
appropriate format ...  This is how short URL's are handled by the way.  I
should know I added this support ...

> file://localhost///machinename/sharename/foldername../filename
> are OK, too.
This is not correct either.  You cannot have two machine names for
one resource.  I think you mean

file:////machinename/<path> for UNC
file:///<path> or
file://localhost/<path> or
file://<hostname>/<path> for Local files


> If you allow non-standard URLs like "file:localFile", the situation gets
> ambiguous.
Again please, please, please do not confuse the words "standard" with ubiquity.
<file>:<whatever> is perfectly legal if you carefully read RFC 1738.  It just
does not follow Common Internet Syntax scheme and can even be very confusing for
developers or users.  But it does not make it "non-standard".  Please see the
reason above ...


> URL like "file://name1/name2/name3" can be pointing either to the local path
> '/name1/name2/name3' or to the path '/name2/name3' located on the computer
> 'name1'.
> 
> If you look at RFC 1738, you'll find that it is defining things in absolutely
> clear and unambiguous way. Yes, you can create new schemes, but redefining
> well-known 'file:' scheme is against the standard.

Where does it say this ???  I cannot find it.  But I found the following
ambiguous statement at section 3.10.  I agree with you in that it is very
confusing from the developers perspective when the implementation varies,
specially for a well know protocol such as "file:", but since "file:" protocol
was meant to designate the local resource and not remote files in KURL's case,
using the appropriate format would have been wrong.   

Finally, I want to say that the "file:" protocol should be support the
format as specified in section 3.10 of RFC 1738, but KURL should
not dump the current format considering the fact that many people
are used to and that it is also supported in both IE and Navigator.
BTW, see what you get if you type

file:////////// in UNIX version of Navigator or
file:////////C:/ in IE and Navigator in Windows

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]