Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To replaceme nt text)

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Tue, 1 Jun 1999 14:10:19 -0700

As best as I can figure out, we are all basically violently agreeing.  

The crux of the arguments being presented seem to be:

You claim that a FQDN is required because it guarantees "authority" to treat
the LHS of a message ID as unique.  You further claim that with a FQDN, you
can guarantee that a message-id is unique to some probability.  And you are
also claiming the converse - without a FQDN, there is no way of guaranteeing
any level of uniqueness of message-id.

My claim that is that even requiring a FQDN is not sufficient to truly
guarantee it to be unique to the required level of probability.  Further I
claim that there is no way of guaranteeing that the FQDN is truely unique in
all the places that 822bis is going to be deployed.  For example, consider a
mailing system that uses RFC822 as its message format running on a
Netware(tm) network.  Netware exports a totally flat namespace, and in such
environments there IS NO FQDN available.  I claim that we cannot write
language that prohibits such a deployment, it is not reasonable to assume
that 822bis messages will be generated in such an environment.

The requirements for 822bis are much stronger than those of 821bis, it's
totally reasonable for 821bis to be scoped to TCP/IP and the Internet, since
it describes an interoperabile protocol that is intended to be deployed on
internet hosts.  However it is out of the question to scope 822bis to simply
TCP/IP networks, the reality is that it will be deployed in many other
places other than that.  And a FQDN @i(REQUIREMENT) forces the 822bis to be
scoped to IP (or rather DNS) networks.

The best we can do is to continue the practise as codified in RFC822 and
822bis - the RHS of a message ID SHOULD be a FQDN, and it is the
responsibility for the generator to guarantee that the ENTIRE message-ID is
unique across time and space (and generation algorithms).  Providing a
recommended generation algorithm is a fine thing.  Providing text to explain
why the SHOULD is a SHOULD (and the pitfalls of violating the SHOULD) is a
good thing.  But REQUIRING (MUST) a FQDN is a very bad thing.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

> -----Original Message-----
> From: Matt Curtin [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 1:48 PM
> To: Larry Osterman (Exchange)
> Cc: 'Robert Elz'; Pete Resnick; DRUMS
> Subject: RE: Message-ID (was: RE: Take 2: References/In-Reply-To
> replaceme nt text)
> 
> 
> >>>>> On Tue, 1 Jun 1999 12:57:59 -0700 ,
>       "Larry Osterman (Exchange)" 
> <[email-masked]> said:
> 
> Larry> Note that it is totally legal for there to be only one
> Larry> sub-domain in the <domain> construct.
> 
> Your assertion that a requirement for FQDN changes RFC822 grammar is
> incorrect.  We are doing _nothing_ to change the grammar: we are
> merely suggesting that codification of the current practice would be
> to require that <domain> be an FQDN.
> 
> Larry> Your comment about authority gets to Robert Elz's comments
> Larry> about message-id generation algorithm naming.  The reality is
> Larry> that even a FQDN is insufficient to guarantee authenticity.
> 
> We're not talking about authenticity at all.
> 
> What we're talking about is the authority that a given generator has
> to claim that its number is unique.  I have no authority to 
> claim that 
> a number I generate is unique within your namespace: I can only
> influence that which is in my own namespace.
> 
> The way that we identify namespace is via FQDN.
> 
> I do not see why this is so difficult for you to understand.
> 
> Larry> And as someone I once knew was fond of commenting: "You
> Larry> have to remember even if there's a one in a million chance of
> Larry> something happening, in systems programming, one in a million
> Larry> happens next Tuesday".
> 
> Blah blah blah.  We beat this to death on USEFOR.  The odds of
> collision are in the same sort of probability as miscalculation.  You
> are welcome to read the Internet Drafts and calculate the probability
> of collision for yourself.
> 
> Larry> Not just the LHS, and not just the RHS, but the
> Larry> entire message-id.  There are many mechanisms to accomplish
> Larry> this, and I claim that RFC822-bis should not REQUIRE any of
> Larry> them, but should instead should allow variability in algorithm.
> 
> We allow for variability in algorithm.  But the standard 
> practice that 
> has emerged is to all-but-eliminate the probability of collision by
> allowing any given Message-ID generator a namespace in which to dole
> Message-IDs.  And that is precisely the purpose of the RHS part of
> Message-ID, as stated in RFC822.
> 
> -- 
> Matt Curtin [email-masked] 
> http://www.interhack.net/people/cmcurtin/
>

---

From: Matt Curtin <[email-masked]>
Date: Tue, 1 Jun 1999 17:29:25 -0400 (EDT)

>>>>> On Tue, 1 Jun 1999 14:10:19 -0700 ,
      "Larry Osterman (Exchange)" <[email-masked]> said:

Larry> The best we can do is to continue the practise as codified in
Larry> RFC822 and 822bis - the RHS of a message ID SHOULD be a FQDN,
Larry> and it is the responsibility for the generator to guarantee
Larry> that the ENTIRE message-ID is unique across time and space (and
Larry> generation algorithms).

I buy this in principle.  But I think that we can require (MUST) that
the RHS be an FQDN, arguing that this is how we divide the namespace
and prevent me from generating Message-IDs which will conflict with
your Message-IDs.

If you still aren't going for it, could you please provide some
examples of where this is a bad idea?

-- 
Matt Curtin [email-masked] http://www.interhack.net/people/cmcurtin/

---

From: Alan Barrett <[email-masked]>
Date: Wed, 2 Jun 1999 11:55:22 +0200 (SAST)

Larry Osterman wrote:
  [about the RHS of a message-id]
> I claim that there is no way of guaranteeing that the FQDN is truely
> unique in all the places that 822bis is going to be deployed.
> For example, consider a mailing system that uses RFC822 as its
> message format running on a Netware(tm) network.  Netware exports a
> totally flat namespace, and in such environments there IS NO FQDN
> available.  I claim that we cannot write language that prohibits such
> a deployment, it is not reasonable to assume that 822bis messages will
> be generated in such an environment.

If there is no other reasonable source of a FQDN, then the software
vendor can assign one that *is* registered in the DNS.  Then you get
message-id's like

        <[email-masked]>

where the left hand side is algorithmically derived in a way
"guaranteed" to be unique across all instantiations of the particular
software product identified by the RHS.

> The requirements for 822bis are much stronger than those of 821bis,
> it's totally reasonable for 821bis to be scoped to TCP/IP and the
> Internet, since it describes an interoperabile protocol that is
> intended to be deployed on internet hosts.  However it is out of the
> question to scope 822bis to simply TCP/IP networks, the reality is
> that it will be deployed in many other places other than that.

Fair enough, but I don't see anybody arguing in favour of
restricting the scope of RFC822bis like that.

> And a FQDN @i(REQUIREMENT) forces the 822bis to be scoped to IP (or
> rather DNS) networks.

No, it doesn't force anything like that.  The FQDN doesn't have to be
associated with the people who own the box that generates the ID.  The
FQDN has to be associated with the people who guarantee that the LHS
is unique across all IDs that share the same RHS, and those people
are often software vendors, who could easily get proper domain names
registered for their products.

--apb (Alan Barrett)