ietf-822
[Top] [All Lists]

Re: Angle brackets surrounding Content-ID

2004-10-13 19:12:11

In <416C6820(_dot_)9010002(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:

Charles Lindsey wrote:
In <416B2775(_dot_)1020507(_at_)erols(_dot_)com> Bruce Lilly 
<blilly(_at_)erols(_dot_)com> writes:

If it never actually happens in the Real World (TM), then it is not a real
situation. It is merely an interesting quirk of the way RFC 2822 was
written.

Such comparisons do in fact occur. Jacob's message which started
this discussion was in fact based on exactly that type of
comparison scenario.

No, Jacob's message made no mention of any comparison which HAD occurred
(and failed). It was purely concerned with a discrepancy between two RFCs,
and an implementor who wanted to do the "right thing".


I have in fact mentioned transcription of various types.

You have mentioned transcriptions which MIGHT occur. You mentioned no
examples which HAD occurred, nor any current software which could cause
them to occur.

I would add that you have failed to provide any concrete example
of specific software which generates identifiers referring to
multiple distinct entities which are identical on the LHS and differ
only in case in the RHS.

I am aware of no such software, and doubt that any such software exists.


writers of new software should simply follow RFC 2822, and that is
the end of the matter.

Evidently you fail to grasp fundamental logic, the nature of the
problem with RFC 2822, and the nature of software development.
Case-sensitive and case-insensitive string comparisons are
mutually exclusive (while there are other types of comparisons
for text, especially for certain character sets representing
specific languages, they do not apply to the non-text protocol
elements being compared here).  One must choose one or the other.
One *cannot* "simply follow RFC 2822", because RFC 2822 fails to
specify which type of comparison is to be used for an id-right
which is not a domain name, nor does it provide any mechanism to
identify when a particular id-right is a (recommended) domain
name vs. when it is something else.

Presumably it makes no specification because it was not considered
relevant. In fact RFC 2822 make no mention of comparison of message
identifiers because such comparison does not arise in the course of any
process that it envisages. AFAICS, the only situation where it considers
processes involving message identifiers is when it gives instructions for
constructing a References field from the Message-ID field of some
presursor, and the instruction is to take the "contents" of that field
which means, in the absence of wording permitting otherwise, without
changing the case of anything.

Likewise I would suppose (I have not checked in detail) that RFC 2821
gives no authority for changing the Message-ID field in any way during
transit.

Thus there seems no circumstance in which a message identifier, once
generated, can legitimately be changed subsequently, in which case it
makes not a blind bit of difference whether any comparison is
case-sensitive or otherwise.

...  And the defect in the RFC 2822 specification
needs to be corrected consistent with long-standing use, viz.
by reaffirming that an identifier RHS is to be interpreted as
a case-insensitive domain name.

If there is nothing broke, then there is no need to fix it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, 
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5