- From: Ed Levinson <elevinso@Accurate.COM>
- Date: Mon, 06 Feb 1995 11:17:03 -0500
- To: "Roy T. Fielding" <fielding@avron.ics.uci.edu>
- Cc: uri@bunyip.com
Roy,
Yeah, I like your suggestion on wording. Does this work better?
The Uniform Resource Locator (URL) scheme, "cid", allows
individual entities within a multipart message body to
refer to one another by their content-id labels.
I could see using msg-ids to refer to other messages would you like to
take that up? CIDs would be real useful now, in my opinion, in the
mimesgml work and I don't see an application for msg-id.
> ... cid URLs should be capable of referencing
> any possible Content-ID. Any characters that are not allowed in a URL can
> be escaped using the %hex encoding method.
I agree, using escapes make sense. Why not use the general syntax from
1521/822 and have the following?
cidurl = "cid" ":" cid-spec
cid-spec = addr-spec ; RFC 822, globally unique
I think that's what you have as the "correct BNF".
Finally, your comment on the Security section makes sense as well.
Thanks.../Ed
On Fri, 03 Feb 1995 23:38:14 PST "Roy T. Fielding" wrote:
> In draft-levinson-cid-00.txt, Ed writes:
>
> > Abstract
> >
> > The Uniform Resource Locator (URL) scheme, "cid", allows
> > compound or aggregate objects in a multipart mail message to
> > refer to one another by their body part labels.
>
> It should also allow objects external to the multipart mail message to
> refer to body-parts of that multipart mail message. In general, I think
> it would be better to use the MIME terms of "entity", "body", and "body-part"
> to refer to things inside a multipart message, instead of "object".
> I encountered this with the HTTP spec.
>
> > ...
> > A cid URL takes the form
> >
> > cidurl = "cid" ":" cid-spec
> >
> > where cid-spec is a restricted form of "addr-spec" as
> > defined in [RFC822]. The purpose of the restriction is to
> > eliminate special characters from the cid URL. Such
> > characters can be problematical in many environments (e.g.,
> > HTML and SGML) in which the cid URL may be used. Cid URLs
> > are a subset of MIME content-IDs and RFC822 message-IDs
>
> I think this is backwards --> cid URLs should be capable of referencing
> any possible Content-ID. Any characters that are not allowed in a URL can
> be escaped using the %hex encoding method.
>
> Thus, the correct BNF would be
>
> ----------------------------------------------------------------------
> cidurl = "cid" ":" cid-spec
>
> cid-spec = local-part "@" domain ; globally unique
>
> local-part = word *("." word)
> word = atom | quoted-string
> atom = 1*<any okCHAR except specials, SPACE and CTLs>
>
> quoted-string = "%22" *(qtext|quoted-pair) "%22"
> qtext = <any okCHAR excepting "%22",
> "%5C" & CR, and including
> linear-white-space>
> quoted-pair = "%5C" okCHAR
>
> domain = sub-domain *("." sub-domain)
> sub-domain = domain-ref | domain-literal
> domain-ref = atom
> domain-literal = "[" *(dtext | quoted-pair) "]"
> dtext = <any okCHAR excluding "%5B", ; => may be folded
> "%5D", "%5C" & "%0D", & including
> linear-white-space>
>
> specials = "(" | ")" | "%3C" | "%3E" | "%40" ; Must be in quoted-
> | "," | ";" | ":" | "%5C" | "%22" ; string, to use
> | "." | "%5B" | "%5D" ; within a word.
> linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE
> ; CRLF => folding
> CRLF = CR LF
> LWSP-char = SPACE / HTAB ; semantics = SPACE
> SPACE = "%20"
> HTAB = "%09"
> LF = "%0A"
> CR = "%0D"
> CTL = <any hex-escaped ASCII control ; %00 - %1F
> character and DEL> ; %7F
>
>
> okCHAR = uchar | ";" | "/" | "?" | ":" | "&" | "="
> uchar = <as defined in RFC 1738>
> ----------------------------------------------------------------------
>
> BUT, I think we could more easily live with just the superset:
>
> ----------------------------------------------------------------------
> cidurl = "cid" ":" cid-spec
>
> cid-spec = local-part "@" domain ; globally unique
>
> local-part = 1*cidchar
> domain = 1*cidchar
>
> cidchar = uchar | ";" | "/" | "?" | ":" | "&" | "="
> uchar = <as defined in RFC 1738>
> ----------------------------------------------------------------------
>
> > ...
> > 3. Security
> >
> > Security issues are not addressed in this memorandum.
>
> It would be more accurate to say that there are no security issues, since
> this section is meant to "address" the security issues.
Received on Monday, 6 February 1995 13:19:36 UTC