Re: x-uri draft

Martin Hamilton (martin@mrrl.lut.ac.uk)
Mon, 07 Nov 1994 21:21:20 +0000

Message-Id: <199411072121.VAA05774@lust.mrrl.lut.ac.uk>
To: "Ronald E. Daniel" <rdaniel@acl.lanl.gov>
Subject: Re: x-uri draft
In-Reply-To: Your message of "Mon, 07 Nov 1994 08:22:38 MST."
<199411071522.IAA24171@idaknow.acl.lanl.gov>
Date: Mon, 07 Nov 1994 21:21:20 +0000
From: Martin Hamilton <martin@mrrl.lut.ac.uk>

"Ronald E. Daniel" writes:

| Seems a reasonable suggestion and you seem to have considered a few
| points about it that are not immediately obvious. The security
| consideration about allowing the user to inpect the URI before it is
| dereferenced is very well taken.
|
| Some minor nits:
|
| In the Abstract, "out-of-bound" should be "out-of-band".

Well spotted! Thanks. I've put up a slightly revised version on the
Web as <URL:http://www.mrrl.lut.ac.uk/xuri-draft>, for what it's worth

| In section 2 - specification - you say "and encoded as per the
| plaintext encoding rules for URLs defined in [Bern94b]". I interpret
| this to mean angle brackets and a colon-delimited scheme identifier.
| That much certainly seems reasonable. My concern is if the plaintext
| encoding rules say any more than that. I don't want to forclose any
| other URI schemes that might do something inside the "opaque string" that
| differs from URLs. The recent thread about the use of colons inside
| URNs is a specific example.

OK, but there _is_ an example... :-)

In my desire to limit the specification to a single paragraph I
skimped a little - I was trying to say that this proposal would be
best advised to use whatever standardised method for writing URIs in
plaintext emerged from the IETF. Appendix A from the URL document is
all there is, right ?

It's also been suggested to me that there is scope for more than just
a single URI header identifying the author of a message, e.g. a list
server might introduce a pointer to itself, and one might want to
associate a URI with the content of a message (or body parts
thereof). This sounds like a winner to me, and I will probably
revise the spec accordingly

Thanks for your feedback,

Martin