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

Ned Freed (
Thu, 02 Nov 1995 15:51:49 -0800 (PST)

Date: Thu, 02 Nov 1995 15:51:49 -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:24:03 -0800"
Cc: Ned Freed <>, Ed Levinson <elevinso@Accurate.COM>,

> On Nov 2,  9:48am, Ned Freed wrote:
> } Subject: Re: host vs hostname (Was: CID: and MID: URL schemes)
> }
> } > 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.

> No, but RFC1123 specifies in sections 2.1 and 5.2.17 that domain literals
> "whose content ... is a dotted-decimal host address" MUST be accepted by
> mailers as a valid host identifier.

I am familiar with what RFC1123 says about domain literals, but I'm not sure
what this has to do with the topic at hand. We are talking about message-ids
here, not addresses. All RFC1123 effectively says is that mail *addressed* to
user@[a.b.c.d] should be delivered to the host with IP address [a.b.c.d] --
i.e. IP-address-based delivery should be possible using this particular

It doesn't say anything about the use or non use of other formats, especially
in the context of message-ids, which have no associated addressing or delivery
implications anyhow.

Perhaps I was unclear, but my intent was first to point out that the *syntax*
of the right hand side of a message-id is in fact incredibly general. (I'm
aware of nothing in RFC1123 that restricts it.) However, operationally a more
limited subset of the syntax is actually employed, and that's all I believe
needs to be accomodated. In other words, the full generality of RFC822 can be
ignored here.

And finally, even with the advent of IPv6 this isn't likely to change
significantly as long as provisions are made to accomodate more alphanumeric
components in a domain literal.