Re: 2822upd-04 line length limits

Bruce Lilly wrote:
> On Sunday 27 January 2008 15:28:08 Tony Hansen wrote:
>> Bruce Lilly wrote:
>>> ...
> 
> 2045 overloads the terms used in a Content-Transfer-Encoding field to
> indicate either an actual encoding transformation or the domain of
> unencoded ("identity transformation" in 2045-speak) content:
> 
>     (3)   A Content-Transfer-Encoding header field, which can be
>           used to specify both the encoding transformation that
>           was applied to the body and the domain of the result.
>           Encoding transformations other than the identity
>           transformation are usually applied to data in order to
> 
> I was referring specifically to the *actual* encoding transformations.
> Thanks for the clarification.

Maybe. But MIME sort of blurs the lines between the identity definitions 
and the encodings. And you sort of blurred the lines by only talking 
about MIME encoding and then using that to say that "extending the line 
length limits" was incorrect.

Until MIME was defined, the notion of binary email was totally 
non-standard and there was no way of expressing such email. MIME gave us 
those tools, and subsequently *did* extend the limits.

Yes, "binary" is in the identity domain. But it does indeed extend the 
limits and it was MIME that did it.

 > ...
>> I suggest changing the wording "extend this specification" to be 
>> "shorten or extend this line length limitation".
> 
> That works for part of the problem, although it only applies to the
> generation (not parsing) part of the 2822 grammars, contrary to the
> description of section 2 provided in section 1.2.3 (the 2822upd-04
> parse grammar contains neither of the restrictions specified in
> draft section 2.3).  And as noted above, there are relevant RFCs
> and errata not mentioned in the draft.

Okay.

However, I don't think it's necessary to mention all potentially 
relevant RFCs and errata. This particular paragraph was using the MIME 
RFCs as examples.

	Tony Hansen
	[email protected]