-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll add this to my open issues list for JEP-0084...
Norman Rasmussen wrote: > It seems that JEP-0084 is inadvertently conflicting with itself by > saying that data must be encoded the RFC 3548 way, and not explicitly > allowing line feeds. > > So something to add to JEP-0084 v0.8 would be to explicitly allow line feeds. > > JEP-0084: User Avatar refers to RFC 3548 (The Base16, Base32, and > Base64 Data Encodings), and in Section 2.1 it says: > > Implementations MUST NOT not add line feeds to base encoded data > unless the specification referring to this document explicitly > directs base encoders to add line feeds after a specific number of > characters. > > In XML Schemas (http://www.w3.org/TR/xmlschema-2/#base64Binary) it says: > > For compatibility with older mail gateways, [RFC 2045] suggests > that base64 data should have lines limited to at most 76 characters in > length. This line-length limitation is not mandated in the lexical > forms of base64Binary data and must not be enforced by XML Schema > processors. > > JEP-0153: vCard-Based Avatars refers to RFC 2045 (Multipurpose > Internet Mail Extensions), and in Section 6.8 it says: > > 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. > > -- > - Norman Rasmussen > - Email: [EMAIL PROTECTED] > - Home page: http://norman.rasmussen.co.za/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQ8KKNF1RSzyt3NURAnI6AKDQdxSUGbfv8/fyd5pjV7uxnY8swwCgn090 pbufEKm0nzxei0aZvoEuc6o= =nTYC -----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
