Re: Relative URL draft 04

Sorry for being slow in getting additional comments to you...

I'm wondering if section 3 ("establishing a Base") should be an
appendix along with section 10. "Any protocol that wishes to allow
relative URLs must define the method by which the base is determined;
here's how to do it for X, Y, and Z" would characterize the appendix.

I don't think the method you outlined for multipart messages in
section 3.5 is clear, or at least, I didn't understand it, or maybe if
I have
     part1: html
     part2: multipart/mixed
         part2a: html
         part2b: text
         part2c: gif
should I be able to say in part2a.html "../part1"? Or do you just use
the content-IDs? I actually think that if we want to support hypertext
in multipart mail we probably should reintroduce "cid:xxxx" as a URL
and translate all of the references to refer to content-ID headers in
the multipart itself, and not try to handle relative URLs in that


A style preference: when you say "have a defined URL syntax in [2]"
I'd rather see "have a defined URL syntax in RFC 1738 [2]" if the
referenced document has a well-known descriptor like that.


>   Relative URLs can be used with these schemes whenever the applicable
>   base URL follows the generic syntax.

>      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? And you might
want a footnote about gopher URLs being broken because of the prefix
type code 00. I'm not sure about them being employed in wais (maybe
they're useful if documents in a wais set refer to other documents at
the same level). I don't know about prospero at all.

I still think "the generic syntax" is too 'generic' a phrase for what
you're talking about, and will confuse the reader who picks up an RFC
and scans a section of it rather than reading the whole thing. I'd
really like something that clearly denotes a 'syntax defined in this
document'.  You didn't like "relative-compatible syntax", I don't
think, but perhaps there's some other terminology that meets our
requirements here?

Received on Friday, 20 January 1995 14:08:27 UTC