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(_at_)[this is a syntactically valid domain literal]
user(_at_)[\[ and so is this \]]
user(_at_)[(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(_at_)host(_dot_)
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