Re: Can we back up a bit and ask some basic questions?An alternate model

The charset identifier is redundant within the examples. The use of the Q/B
encoded like words as MAIL FROM nouns identifies the charset. Similarly, the
xn-- identifies the ACE. Unless 8 bit is used, this is not needed.

The use of the M-headers should be renamed as X- headers for experimental
usage. But, isn't the split between 2821 and 2822 a design decision to keep
the message payload separate from the transport mechanism ? This looks like
a tie in between 2821 & 2822.

In general, smtp implementations should keep data from 2821 separate from
the 2822 message object, storing them internally as some form of meta data.

jeffrey j zahari

----- Original Message -----
From: "Simon Josefsson" <[email protected]>
To: "Edmon Chung" <[email protected]>
Cc: <[email protected]>
Sent: Friday, February 21, 2003 8:19 AM
Subject: Re: Can we back up a bit and ask some basic questions?An alternate
model


>
> "Edmon Chung" <[email protected]> writes:
>
> > Good to hear from you.
> > I actually agree with you about the M- headers thing... i wasnt so sure
to
> > begin with.
> > But in order to phase out the ACE fallback, there needs to be new header
> > fields that could use email addresses in other forms than ACE...  What
are
> > your thoughts?
>
> I don't think the issues need to be linked -- it would be possible to
> phase out punycoded address in SMTP MAIL FROM but keep them in message
> headers.  It seems to me that internationalization of RFC 2821 and
> POP3 and IMAP is independent of internationalization of RFC 2822.  It
> seems unlikely that it will be possible to move away from punycode in
> RFC 2822 soon because it is a stored format rather than a interactive
> protocol like RFC 2821.  In a protocol you can agree on new
> non-back-wards compatible behaviour for a single session (such as your
> proposal) because all parties that are interested in the session are
> present and can negotiate, but in a storage format any new features
> should either be developed within the original or specification, or a
> completely new version of the format should be developed, because all
> parties that will see a certain RFC 2821 message is not present and
> able to interact with the sender to negotiate what features to use.
>
> A separate issue: I think your document should say that the strings
> passed in MAIL FROM (whether as ACE or UTF-8) should be processed by
> the IMA stringprep profile.
>
>