Re: Just a short quick question, relation to text of 1.1.3 in 2396bis

Hi Mike, not a complaint.
I think the question is off-topic but I also lack a list 
to ask such questions of use; perhaps you know of a users 
group I can post too?

The new drafts are a lot better than current standard.


In regards to my last post, The draft leads me to 3305, and then
the references for URL terms in 2396bis and I was wondering if 
that was the correct way to read these documents :

http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt
(below I remove the other ref)
1.1.3  URL

Future specifications and related documentation should use
  the general term "URI", rather than the more restrictive terms URL
  and URN [RFC3305].



PS:

A good roasting is always acceptable :)


A lot of this comes down to my understanding of these drafts as my file
question – I saw a question in relation to something I have wanted to
know and decided to post. On my PC with windows file://home and
file:////home both relate to the same thing – I was using file://home
where I should be constructing my URL using the entire spec so I end
up with file:////home.



The FQDN in this case is file://home.kitchenpages.net/ but for some
reason its not accepted in any case for the file protocol (unknown
reason- however I can resolve by internal windowsNT using DNS on http
according to current spec). I have to use windows shares for file
protocol and avoid FQDN as above file does not work and IP addresses
which work for inifiles.hpp (as below states not to use IPaddress)...
:(



I always thought that for linux users had to use the format
'file://<host>/<path>' to access files on windows systems
without the '\\' for windows shares because they are linux clients.


Al's reply to my file question pointed out that I should of be
constructing my URIs using protocol File to as the values are
somewhat equated (my browser voodoo?).
Linux users should be able to browse windows systems using file:\\\\


:)
Thanks again for your time in reply to previous post.
Kindest regards,
Jason


Message-Id: <200409022107.i82L784r016656@>

---------------------

Kitchen Pages wrote:
> Just a short quickie question

I see various question marks in your message, but no actual questions,
at
least none that I can follow well enough to provide an answer for. I
suspect
others on the list haven't responded because they feel the same. What
is
your
quickie question?

> The text below is from one of my books on how to use/programme for
BCB
> c++ (Borland Builder) published in 1998 which states:

At the risk of sounding like Roy Fielding, whatever
(mis-)understandings
you
have picked up from that book, or from anywhere other than the RFCs
themselves, are irrelevant. A book about some programming language can
say
what it wants about anything. I tend to assume that the actual specs
are
going
to be more accurate and precise than the executive summary you get in a
book,
especially if the topic is peripheral to the main topic of the book.

That said, the concepts that the URI generic syntax embodies have been
refined
over time, influenced by the nuances of HTTP and the kind of situation
described in the Borland book you quoted. Resource has been decoupled
from
representation, and identification has been decoupled from retrieval.
Consequently, a clear distinction between a "locator" and a "name" is
not
necessary to maintain at either the syntactic level or the semantic
level, for
the purposes of resource identification.

Location may be important in the definition of a scheme, for
implementation,
but even in the case of the http scheme, location is only relevant in a
URI's
authority component when one is using a resolver that uses that
component
in
the usual manner, dissecting it into a host, port, and userinfo, and
talking
over a network -- it could just as easily use a catalog instead,
effectively
treating the http URI as an opaque identifier rather than having any
location
semantics implicit in the URI at all.

> In a nutshell as I am - I was wondering ? that perhaps the URL
> references used in the draft text could be stated; like an RFC number
> as the "Informative References" seem to have multiple choices which
may
> not be a bad thing but it is somewhat confusing considering the
> reference to REC2141 for URN (or should I use that?).

I can't figure out what you're referring to ("the URL references"?),
what
you're asking for ("stated"? "use RFC 2141 for URN"?), or what your
complaint
is, exactly, with the current draft.

If you have an editorial suggestion for improving the Informative
References
section, then my advice would be to please try to state it clearly, for
better
results: "RFC 2396bis draft 06 currently says..., which is confusing
because..., and here's what (or the kind of thing) it could say that
would
mitigate that confusion..." ...then prepare to be roasted by Roy. :)

-Mike

Received on Saturday, 4 September 2004 02:54:43 UTC