Re: [EAI] I-D Action: draft-ietf-eai-rfc5335bis-11.txt

[John C Klensin <[e-mail]>]

--On Tuesday, 26 July, 2011 07:12 -0400 Dave CROCKER
<[e-mail]> wrote:

>> The 78 character limit remains defined in terms of
>> characters, not octets, since
>> it is intended to address display width issues, not line
>> length issues. </t>
> 
> I'll ask a "due diligence" question:
> 
>     Are we certain that this long-standing 78-character limit
> has not produced hard buffering limits in software that really
> make it an installed base of 78-octets?

Dave, I've seen far more MUAs in recent years that pay no
attention to the 78 character limit then I have ones that, e.g.,
build fragile buffers around it.   Indeed, any contemporary MUA
that supports "flowed", binary (BDAT) input,  or a few other
things already has to be adequately careful about that.   

However, the question is reasonable.  I'd think a reasonable
response might be to add a comment in the Security
Considerations section to the effect that the use of UTF-8 --and
hence inherently variable-length strings that might turn out to
be longer than one might naively expect-- calls for caution
about buffer sizes and overflows.  That would cover not only
this case but a number of others in which software might
reasonably buffer subfields.   For example, A-label to U-label
conversion can produce either longer or shorter U-label  strings
than the A-label original and only the latter is constrained by
the DNS limit on label length.

I note that this issue is not covered in the Security
Considerations section of RFC 3629.

   john