Re: host vs hostname (Was: CID: and MID: URL schemes)

Ned Freed (
Thu, 02 Nov 1995 09:48:15 -0800 (PST)

Date: Thu, 02 Nov 1995 09:48:15 -0800 (PST)
From: Ned Freed <>
Subject: Re: host vs hostname (Was: CID: and MID: URL schemes)
In-Reply-To: "Your message dated Thu, 02 Nov 1995 11:19:22 -0500"
To: Ed Levinson <elevinso@Accurate.COM>

> 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

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.