- From: Al Gilman <asg@severn.wash.inmet.com>
- Date: Wed, 22 Nov 1995 16:24:08 -0500 (EST)
- To: moore@cs.utk.edu (Keith Moore)
- Cc: asg@severn.wash.inmet.com, moore@cs.utk.edu, ietf-types@uninett.no, uri@bunyip.com
To follow up on what Keith Moore said ... Perhaps it's best to think of it this way: 1. content-ids and message-ids aren't URLs. Yes. 2. notwithstanding #1, it may be useful to extend the URL notation to allow references to content-ids and/or message-ids. Yes. (they aren't necessarily URNs, either...though they have some of the desirable characteristics of URNs, and they might someday be incorporated into a URN name space.) Well, almost consensus. They meet Roy's semantic test. I kept referring to URI language because I had just read RFC 1808 on relative URLs and the generic syntax there is talked about as a generic URI syntax. That's where I picked that up. I am not presuming that URN status would change the syntax one whit. It is a difference in what you expect from the citation. The rabbit out of the hat trick I was trying to pull was to call the mid: scheme by the ambiguous "URI" term to get it through standardization, and then after the fact come back and say "Poof! You already _have_ an example of a URN scheme!" Issues: 1. the minor matter of the punctuation in: scheme-name: "message-unique@path-to-host" punctuation "part-unique@blah-blah-blah" punctuation ::= # | ? | / ; Resolve at meeting 2. I wanted to turn on header encoding in parameters, thus: (after the above) *( ; header-name=header-value-phrase ) header-name ; per RFC 822 header-value-phrase ; per RFC 822 quoted and escaped asreq. Is good for legacy multi-mode, multi-server objects like FAQs.
Received on Wednesday, 22 November 1995 16:25:13 UTC