Re: Relative URL draft 04

The reason for putting 'establishing a base' in an appendix is that it
isn't exhaustive. It doesn't define how to establish the base URL for
all situations, nor can it. What's there now is a set of examples;
some of them correspond to well-established practice (like the base
for things transported by http, while others are things that you've
made up while writing this document (e.g., establishing a base for
multipart mail messages).

I don't believe that your assertion "The method of establishing a base
must be part of the standard" holds up. You assert it, but you don't
justify it. In any case, even it if must be part of 'a' standard, it
isn't clear that it must be part of *this* standard, which defines the
syntax and semantics of relative URLs.

>>>      gopher     Gopher and Gopher+ Protocols
>>>      news       USENET news
>>>      nntp       USENET news using NNTP access
>>>      prospero   Prospero Directory Service
>>>      wais       Wide Area Information Servers Protocol
>> 
>> 
>> I don't think news and nntp belong in there, do they?

>Yes.  There is no reason why they can't use relative URLs when listing
>the available groups and/or articles.

Two things: most importantly, the defined syntax for news and nntp
URLs don't include any semantics for "/".  At best, you're left saying
that a raw "<message-id>" is a relative URL to a "news:<message-id>"
URL. The syntax for available groups doesn't allow you to say that
applying ".." as a relative URL to "news:alt.binaries.parsers" would
get you "news:alt.binaries". And using "../3" in
"nntp://news.org:119/alt.binaries/12" doesn't seem particularly useful.

I hadn't really gone over your BNF, but I'm puzzled how:

!    absoluteURL = generic-RL | ( scheme ":" *( uchar | reserved ) )
  
+    generic-RL  = scheme ":" [ relativeURL ]
+ 

leads one to allow a relative URL as a kind of absoluteURL.

Received on Sunday, 22 January 1995 15:57:00 UTC