Re: [EAI] Comments on draft-ietf-eai-downgrade-04

["Charles Lindsey" <chl at clerew.man.ac.uk>]

On Tue, 31 Jul 2007 11:22:28 +0100, <fujiwara at jprs.co.jp> wrote:

> Thank you very much for your comments.
>
> > From: "Charles Lindsey" <chl at clerew.man.ac.uk>
> > Sorr
> > > 4.  SMTP Downgrading
> > >   MTA replaces non-ASCII mail address with specified alternative US-
> > >    ASCII address when downgrading.  Before replacing, decode the ALT-
> > >    ADDRESS parameter value because it is encoded as xtest [RFC3461].
> >
> > Eh? That last sentence only applies to an ORCPT parameter, I think.
>
> smtpext-07 section 2.4 says:
> 	ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value
> 	ALT-ADDRESS-esmtp-value=xtext

Hmmm! When did we decide that - I had not spotted it, though it seems to  
have changed between March and April this year? What was the reason (I  
don't necessarily object, but I would like to understand it).

> > > 5.  Email header fields downgrading

> > >    o  Downgrading Address header fields
> > >      From:
> > >       Sender:
> > >       Reply-To:
> > >       To:
> > >       Cc:
> > >       Bcc:
> > >       Resent-From:
> > >       Resent-Sender:
> > >       Resent-To:
> > >       Resent-Cc:
> >
> > But that is only the present list. Surely the process you describe MAY  
> > also
> > be used for any header defined in the future which contains an  
> > <angle-addr>
> > etc.
>
> It is true but currently supported header fields list is necessary.

Yes, but I see no reason why future headers that include a <mailbox>  
should not be included. Your list if fine in order to make sure that all  
implementors cover at least those cases correctly. Perhaps:

    Any address header fields (i.e. those containing one or more  
<mailbox>s)
    that may be defined in future MAY be downgraded by applying the same
    process.

And similar wording for other cases later on.

> > The upgrade/display mechanisms you describe in A1 and A2 would work
> > just fine on such headers.

The point is not whether we should allow any future Address header fields,  
but whether sensibly written MUAs would be able to upgrade them (i.e., if  
they are written to detect whether both a Downgraded header and a normal  
header of the same name are present, without checking it against any list,  
then they should be able to upgrade it without problem by decoding any  
RFC2047 in the Downgraded header, and discarding (or renaming) the other  
one. It is rather similar to what is in RFC2047, which claims to work on  
ANY unstructured header, or ANY structured header with <comment>s,  
<phrase>s etc in it. In fact it should be easier than RFC2047, because  
2047 requires you to consult the Delphic Oracle to discover whether the  
unrecognized header is structured or not. In practice, I suspect that the  
great majority of MUAs, if they see anything that is syntactically an  
encoded word (or even a poor attempt at an <encoded-word>) they simply  
decode it regardless.

> > No, that is not right, becuase if there is both a <display-name> and a
> > <non-ASCII> you would then get:
> >
> >    <encoded-display-name> Internationalized Address "<encoded-word>"
> > Removed: ;
> >
> > which might not by a syntactically valid <group> according to RFC2822.  
> > Well
> > I am not quite sure about that, but in any case it would look better if  
> > you
> > cuold arrange it as:
> >
> >    Internationalized Address <encoded-display-name> "<encoded-word>"
> > Removed: ;
>
> According to RFC2822,
>
> word            =       atom / quoted-string
> phrase          =       1*word / obs-phrase
> display-name    =       phrase
> group           =       display-name ":" [mailbox-list / CFWS] ";" [CFWS]
>
> RFC 2047 updates phrase
> phrase = 1*( encoded-word / word )
>
> "encoded-word word word encoded-word word:;" is allowed.

Yes, my suggested wording should be extended to cover that case. In fact,  
all you need is a rule

  encoded-display-name = 1*( encoded-word / word )
> And more, according to RFC 2047 section 5,
>     + An 'encoded-word' MUST NOT appear within a 'quoted-string'.
>
> So, I removed double quotes which enclose an encoded-word.

Agreed. Essentially you are saying that the <addr-spec> is to be encoded  
as a single <encoded-word>, as opposed to <encoded-display-name> which can  
be as complicated (and confusing :-) ) as you choose to make it.

> > >      Content-Type:
> > >       Content-Disposition:
> >
> > But again, this applies to ANY header that contains <parameter>s as  
> > defined in RFC2045. ...

And this time that should be no problem, because there is no Downgraded  
header to worry about. and the result of the downgrading is automatically  
consistent with all existing standards.


> > Here, however, you need to specify how to downgrade a message/utf8smtp,
> > since there is a promise in section 4.6 of
> > draft-ietf-eai-utf8headers-06.txt
> > that such a downgrading (to message/rfc822) would be defined here.
> >
> > Presumably this would involve the usual recursive descent through the
> > message/utf8smtp, downgrading individual headers as described above, and
> > applying Content-Transfer-Encodings to bodies, as needed.
> >
> > And, having done that, you could also say that downgraders MAY do the  
> > same
> > thing to message/rfc822. Yes, I know we have forbidden these to contain  
> > any
> > utf8smtp headers, but such "leaks" are surely going to happen, so being
> > "liberal" here might undo some such blunders.
>
> This comment is not agreed in WG.

OK, it is just a suggestion for the WG to consider. The first job is to  
get a proper description of how to downgrade a message/utf8smtp. But I  
suspect that once an implementor had implemented that correctly, it would  
only take half a line of extra code to do message/rfc822 as well.
> In my opinion, a rfc822 message which contains message/utf8smtpMIMEtype
> part confronts 7bit transport, it may be encoded to BASE64
> and its MIME headers will be
>   Content-Type: message/utf8smtpMIMEtype; charset="UTF-8"
>   Content-Transfer-Encoding: base64
>
> This rfc822 message is deliverable via 7bit transport.

Yes, it breaks existing standards, but the WG has already decided to do  
that :-( .


> > >A.2.  Displaying technique 2
> > >         +  Remove the header field which is the same with the  
> > generated
> > >             ASCII only header from the header fields.  If the headers
> > >             contain [RFC2047] encoded part, decode it before  
> > comparison.
> >
> > But that last sentence will not always work because, sometimes, the
> > [RFC2047] encoded part might have been present before downgrading. And,  
> > in
> > any case, you have to unfold before doing the comparison.
>
> It is a difficult problem. RFC 2047 encoding does not preserve a space
> between words. it needs further consideration.

I am pretty sure you are wrong there. Can you explain further?
> > >Appendix B.  Examples
> > >B.1.  Downgrading example 1
> > >   Result of the header downgrading.
> > >   Return-Path: <ASCII-FROM>
> >
> > It is customary to insert the Return-Path: at the _end_ of the headers.
>
> Some MTA insert the Return-Path: at the top of the headers.

Indeed, but best to use the more common case in examples.

> > The previous draft had a useful paragraph here about a MIME encapsulated
> > subject header. Why has it been removed?
>
> Is the paragraph this?
>
> |  And more, the body part contains UTF-8 message.  "ascii user" needs
> |  to accept UTF-8 mail body and UTF-8 subject which is MIME encoded.

No, it was

   This downgraded message's header part contains ASCII characters only.
   But it still contains MIME encapsulated subject header which contains
   UTF-8 characters.  And more, the body part contains UTF-8 message.
   "ascii user" needs to accept UTF-8 mail body and UTF-8 subject which

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;                      
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima