Charles Lindsey wrote:
In <416B2775(_dot_)1020507(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
No Charles, this is not merely "possible scenarios". It is about
the very real situation of comparing identifiers.
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.
Since I have repeatedly asked you for instances of where this has actually
happened in the Real World, or for examples of existing agents which
explicitly change the case of the id-right of a msg-id when copying it
(during transit or otherwise), and you have signally failed to provide
such examples, then I conclude that you are unaware of any such examples.
Moreover, nobody else on this list has produced such examples.
I have in fact mentioned transcription of various types.
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. Not that that would make any substantive
difference to the discussion, since any such software would fail
to conform to the (full Standard) RFC 822 requirement for uniqueness
of such identifiers -- but since you seem to be enamored of pointless
ultimata... "Moreover, nobody else on this list has produced such examples."
Therefore, I conclude that this minor change from RFC 822 to RFC 2822 has
no practical significance in the Real World and has not lead to any
problems of interoperability. In which case, since RFC 2822 supersedes RFC
822,
RFC 2822 does not in fact supersede RFC 822. RFC 822 is a full
Standard, whereas RFC 2822 is merely a Proposed Standard. If and
when some successor to RFC 2822 achieves full Standard status,
that document may well supersede RFC 822. Hopefully by then the
problems identified with RFC 2822 will have been repaired.
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. One cannot rely on querying
DNS for several reasons: one may be offline and therefore DNS is
unavailable, a name which may once (i.e. at time of message
generation) have been a valid domain name may have since
expired, a string which was not at time of generation a valid
domain name may have become registered as a domain name,
temporary DNS failures may result in inability to determine
status of a prospective name, etc. RFC 2822 of course provides
for parsing "old" messages, including those generated under
RFC 822 and its predecessors; in fact UAs and other software
does need to process archived messages and that should be
performed according to the long-established rules (viz.
identifier RHS is a domain name and domain names are
case-insensitive). Existing software couldn't change
worldwide overnight even if RFC 2822 provided some concrete
mandate w.r.t. case-sensitivity (which it doesn't). Even
if "King Charles" could wave a magic wand and produce such a
change, there is still a need to be able to properly handle
archived messages in accordance with RFC 724/733/822/1034/1035
rules. The only sensible thing for software developers at
this time is to continue to use the clear and precise RFC 822
rules which continue to be compatible with the RFC 2822
recommendation. 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.