Re: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-01.txt

[Dave Crocker <[e-mail]>]

> OLD:
> 
>     Fully interoperable email uses 7-bit ASCII, although some email	
>   	   handling paths directly support 8-bit ASCII.  Emoji characters are	
>   	   drawn from the space outside of 7-bit ASCII.  For email handling	
>   	   paths that are 8-bit clean, the an emoji character does not need	
>   	   special encoding.  If the path from author to recipients is not known	
>   	   to be 8-bit clean, The emoji character SHOULD be encoded using	
>   	   [MIMEencode].
> 
> NEW:
> 
>       Emoji and any other code points outside the ASCII range MUST be encoded
>       using [MIMEencode], unless the message is Internationalized [RFC6532].



This thread is prompting a meta-thought. The thought is mostly driven by 
the need for simplicity, especially across multiple specifications. The 
specific directive applicable here is that normative redundancy is bad.

That is:

A specification which is only providing usage detail, within an 
established context, rather than providing new context rules, SHOULD NOT 
make additional normative declarations, within that context.  Normative 
language is needed only if the new specification is /changing/ that context.

Addition of normative declarations that merely replicate established 
normative declarations invites errors.



Consequently, I'll now suggest this wording, for this specification:


Fully interoperable email uses 7-bit ASCII, although some email handling 
paths directly support 8-bit ASCII.  Emoji characters are drawn from the 
space outside of 7-bit ASCII.  [IntHdr] covers data encoding for email 
header fields, along handling paths that are known to be 8-bit clean. 
[MIMEencode] covers encoding for paths that are not known to be 8-bit clean.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net