John C Klensin wrote:
--On Friday, February 27, 2009 16:04 +0100 Arnt Gulbrandsen
<arnt(_at_)oryx(_dot_)com> wrote:
"SHOULD doaddress lookups case-insensitively", IMHO, doesn't
belong in an architecture document.
Do you think it's fair for another RFC to say "MUST do
case-insensitive matching of local-parts" if the email-arch
RFC says "globally opaque and [...] to be interpreted only by
the entity specified by the address's domain name"?
This is one of many examples of why I'm concerned about putting
this document on the standards track. 2821/5321 says that these
are case sensitive but that depending on that is a bad idea (and
doesn't say it in those words). Any statement that is not
_exactly_ the same as what 5321 says will be taken by someone as
contradicting that document and make our situation worse, not
better, even if only slightly so. And a statement that is
identical to what 5321 says will prevent improvements in that
text for 5321bis (or introduce the same confusion).
John,
First, I don't see discussion of this issue in 5322. Perhaps I missed it.
Second, 5321 says:
"The local-part of a mailbox MUST BE treated as case sensitive."
A /MUST/ is a completely clear an unambiguous statement.
Third, if that normative status changes, it will have all sorts of follow-on
effects. Changing the architecture document to reflect it would be merely one.
So it seems an awfully tactical issue to have such a strategic impact on the
status of the document.
What you raise is really the meta-issue of having anything repeated or
abstracted in one normative document, about another. Your logic would seem to
say that no normative document should ever make such a reference, summarization
or abstraction.
By way of example, and in terms of practical impact, if folks were seriously
concerned about sucy synchronization between two specifications, then the
redundancies and labeling and semantic variations between 821/822, 2821/2822 and
5321/5322 would have been resolved.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net