On Aug 1, 6:33pm, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > Standarizing things has benefits and costs.
}
} But standardizing user interfaces, no matter how beneficial, is none of
} the IETF's business.
I'm wondering if we have two separate points of dispute getting mixed into
the same argument.
The draft as Chris wrote it consists of two major parts: A syntax for
subaddresses in local parts, and rules for how various agents should
treat local-parts that include subaddresses.
I agree that some of the rules for the semantics of subaddressing could
intrude on user interface and host policy. The one and only rule that
is necessary is that the primary address always identifies the same
entity regardless of what subaddress is attached. (If that primary
entity wants to dispatch certain subadresses to other entities, that's
entirely up to the primary entity or its representative.)
Further, the interpretation of local-parts as address plus subaddress
can be limited entirely to the host identified by the domain-part; it's
neither necessary to require nor necessary to prohibit interpretation by
intermediaries like mailing list managers.
The syntax, however, is entirely a data format, not a user interface.
I think Dan's remark above is directed at the semantics of local-parts;
but it's not clear whether the "benefits and costs" remark (sorry, don't
remember who wrote it) is referring to the entire draft or only to the
syntax dispute.
I want to stick to the syntax for now.
Even if that syntax is opaque to relays and other intermediaries, it
is necessary for it to be transparent to LDAs and submission agents
within the interpreting domain. One way to make the syntax transparent
is to standardize it; I've been asking for alternatives, but the only
suggestion so far is that we throw away combinations of agents that
don't already understand one another. Not very helpful either to those
who'd like to change existing agents to be able to understand, nor to
those who want to write new agents.
One alternative that I've thought of is to make it possible to discover
the syntax. This is effectively what Dan's ``addalias'' program does
by sharing its configuration file. It would certainly be possible to
create a simple protocol, possibly as part of the ietf-submit work
already in progress, for remote clients to learn the local-part syntax
of their server host.
However, we've already seen how well such a discovery mechanism works
with hierarchy separators in the IMAP4 protocol: To wit, badly, if at
all. Nearly everyone agrees that it would have been preferable to pick
a hierarchy separator and standardize it, even if that means restricting
the mailbox names that the server can present.
The situation here is no different; standardizing a character to separate
primary address from subaddress is far more workable than standardizing
a discovery mechanism, even if it means restricting the primary addresses
that a server can support.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com