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

Ned Freed (NED@innosoft.com)
Thu, 02 Nov 1995 09:48:15 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ed Levinson: "Re: CID: and MID: URL schemes"
- Previous message: Ed Levinson: "host vs hostname (Was: CID: and MID: URL schemes)"
- Maybe in reply to: Ed Levinson: "host vs hostname (Was: CID: and MID: URL schemes)"
- Next in thread: Ned Freed: "Re: host vs hostname (Was: CID: and MID: URL schemes)"

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

    From: Ned Freed <NED@innosoft.com>

    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>

    Message-Id: <01HX5WUE0QDO9BVL0H@INNOSOFT.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
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

- Next message: Ed Levinson: "Re: CID: and MID: URL schemes"
- Previous message: Ed Levinson: "host vs hostname (Was: CID: and MID: URL schemes)"
- Maybe in reply to: Ed Levinson: "host vs hostname (Was: CID: and MID: URL schemes)"
- Next in thread: Ned Freed: "Re: host vs hostname (Was: CID: and MID: URL schemes)"