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

[fujiwara at jprs.co.jp]

> From: "Charles Lindsey" <chl at clerew.man.ac.uk>
> >> > 5.  Email header fields downgrading
> >> 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.

OK, I now rewriting as
  5.  Email header fields downgrading
      <mailbox>, <word>, <comments>, <unstructured>, MIME parameter <value>
      downgrading definition
  5.1.  Each header fields downgrading
      header fields listing and refer each downgrading.

requirements for future defined header fields may be useful.

> >> 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.

The upgrade/display mechanism only helps recipients to recognize the
original header fields.

> > 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 :-( .

Which standards?

> >> >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

OK, the same part. I added it in security consideration section.

--
Kazunori Fujiwara, JPRS


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