Re: Base64 -- do we really want/need line breaks every 76 characters?

Given the way we are going, this line break requirement should be
removed as Brian suggests. Afterall, Canonical XML removes all new
lines inside tags so, unless you have new lines in content, you get
one line out no matter how long.

I belive the email limit is 1000 characters (actually 998 not counter
the CR-LF) but in any case if you try to mail "text" that doesn't meet
the requirements of your email transport, it just gets QuotedPrintable
or Base64 encoded. (Yes, a 10,000 character long line of "Base64"
would get Base64'ed a second level if sent over normal text email.)

Thanks,
Donald

From:  Martin Duerst <duerst@w3.org>
Message-Id:  <4.2.0.58.J.20010523094402.03db42d0@sh.w3.mag.keio.ac.jp>
Date:  Wed, 23 May 2001 09:46:52 +0900
To:  "Brian LaMacchia" <bal@microsoft.com>, <w3c-ietf-xmldsig@w3.org>
In-Reply-To:  <BCDB2C3F59F5744EBE37C715D66E779CEAB6CD@red-msg-04.redmond.
	      corp.microsoft.com>

>This should be fixed in XML Schema, not in Signatures, I guess.
>On the other hand, it's not a bad idea to have line breaks in
>the Base64, just streaming out something as a very long line
>(e.g. 1000000 chars) doesn't seem like a good idea. It will
>cause problems sooner or later. For example, SOAP may be used
>over mail, and what happens then?
>
>Regards,  Martin.
>
>At 17:31 01/05/22 -0700, Brian LaMacchia wrote:
>>Folks--
>>
>>Currently, XMLDSIG references RFC 2045 (one of the MIME RFCs) for a
>>definition of Base64 encoding/decoding.  (See section 6.8 of [1].)  It
>>has been pointed out to me that RFC 2045 *requires* that Base64-encoded
>>content have line breaks at least every 76 characters.  Paragraph 6
>>reads as follows:
>>
>>    The encoded output stream must be represented in lines of no more
>>    than 76 characters each.  All line breaks or other characters not
>>    found in Table 1 must be ignored by decoding software.  In base64
>>    data, characters other than those in Table 1, line breaks, and other
>>    white space probably indicate a transmission error, about which a
>>    warning message or even a message rejection might be appropriate
>>    under some circumstances.
>>
>>I can't see any reason for XMLDSIG to inherit a line-length limitation
>>that appears to have been there for mail-specific reasons.  The SOAP 1.1
>>submission [2] removes the line length limitation in their use of
>>Base64; Section 5.4.3 of SOAP reads as follows:
>>
>>    The recommended representation of an opaque array of bytes is the
>>    'base64' encoding defined in XML Schemas [10][11], which uses the
>>    base64 encoding algorithm defined in 2045 [13]. However, the line
>>    length restrictions that normally apply to base64 data in MIME do
>>    not apply in SOAP. A "SOAP-ENC:base64" subtype is supplied for use
>>    with SOAP.
>>
>>I propose that XMLDSIG adopt language similar to SOAP and not require
>>applications to insert line breaks at least every 76 characters.
>>(Conforming implementation will still accept line-limited encodings
>>since they have to ignore any found whitespace in the Base64 string.)
>>
>>                                         --bal
>>
>>[1] http://www.ietf.org/rfc/rfc2045.txt
>>[2] http://www.w3.org/TR/SOAP/
>

Received on Tuesday, 22 May 2001 22:42:21 UTC