To: email@example.com Cc: firstname.lastname@example.org In-Reply-To: email@example.com's message of Wed, 18 Jan 1995 17:37:49 -0800 <95Jan18.firstname.lastname@example.org> Subject: Re: Relative URL draft 04 From: Larry Masinter <email@example.com> Message-Id: <95Jan20.firstname.lastname@example.org> Date: Fri, 20 Jan 1995 11:07:45 PST 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 multipart/mixed 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 situation. ----- A style preference: when you say "have a defined URL syntax in " I'd rather see "have a defined URL syntax in RFC 1738 " 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?