At 10:04 AM 5/3/2002 +0100, Nick Shelness wrote:
>Moving on, there is clearly rough consensus that it makes no sense to
>restrict domain-names (yes, names) to an ASCII alphabet, though clearly a
>pure ASCII encoding is required for backward compatibility.
yes.
> I think that
>achieving a similar consensus for local-parts will be difficult. I for
>one, will take a lot of convincing.
RFC3192 and RFC3193 focus on using a template for local-part that pertains
to encoding telephone information.
However if one looks at the specifications with from a broader perspective
they will note that a generic template is provided, and alas, it has an
X.400 parametric tone to it.
Simplistically, the template is of the style:
<type> "=" <prime-string> *( "/" <parameter-name> "="
<parameter-value> )
such as:
FAX=+12027653000/T33S=6377
However it is an optional format, to be used only when the local-part
string really needs to be parametric. This is in contrast with X.400,
where the structure was required even when it was not useful.
Agreed. Additionally, the optional fields in 3192 and 3193 are associated with
offramp functionality, which makes the concerns about being able to map the
local-parts of such addresses to mailboxes moot.
Some of the X.400 fields had a flavor similar to the FAX parameters (the postal
delivery stuff, for example) but it was never entirely clear to me where the
boundary between matched and unmatched fields was. And there were around 48
possible fields in an X.400 address... What a mess.
I think we'll be OK as long as we stay clear of adding any complexity
to the mapping from local-parts to mailboxes.
Ned