- From: Ned Freed <NED@innosoft.com>
- Date: Thu, 02 Nov 1995 09:48:15 -0800 (PST)
- To: Ed Levinson <elevinso@Accurate.COM>
- Cc: uri@bunyip.com, ietf-822@list.cren.net
> However, converting id-spec' into a message-ID (content-ID) becomes > problematical. Rfc 822 requires, I think, that a message-ID containing > a host's IP address (hostnumber) have the form "[" digits "." digits "." > digits "." digits"]" RFC822 actually doesn't specify what a domain literal looks like or how it should be interpreted. You could have [a], [a.b], [a.b.c], [a.b.c.d], [a.b.c.d.e], or whatever. There is no requirement that the parts be numbers either, and in fact pretty much anything goes. For example: user@[this is a syntactically valid domain literal] user@[\[ and so is this \]] user@[(this is the literal value and NOT an RFC822 comment)] I've never seen such things in practice, thank goodness. Once IPv6 is upon us you can expect the specifics of the format here to change. I don't know what the final format will be -- the current trend seems to be towards using dot-separated hex nibbles. If this is what gets adopted I doubt we'll see much use of IPv6 domain literals! > Is this reading of rfc822 correct or should id-spec be > local-part@host. In practice you'll find that [a.b.c.d] is almost universally supported, but specifying two 16bit values [a.b] often works and so does specification of a single 32bit value [a]. I think that anything that allows for a variable number of alphanumeric fields in a domain literal should be OK both now and in the future. I don't think you need to cater to domain literals in their full syntactic glory -- practically nobody supports all the variations. What I have seen in practice (only yesterday, as a matter of fact) is something like this: message-id: <id(comment)@host> The (comment) here is NOT actually part of the id, but some agents treat it as though it is. I don't know whether or not you want to mention this sort of nuance in your specification though. Ned
Received on Thursday, 2 November 1995 13:08:18 UTC