Hello, I have been losing sleep over this for the past few days and I am now not sure if there is something wrong with RFC2045 or my interpretation of it. I am hoping someone can confirm that it is the latter.
I have come across this while writing a chapter on Codec and hence my detailed examination of the said rfc for Base64 transformations. Here is a link to this rfc: http://www.ietf.org/rfc/rfc2045.txt Consider section 6, second paragraph: "It is necessary, therefore, to define a standard mechanism for encoding such data into a 7bit short line format". This line establishes that the document defines a mechanism for encoding data into 7bit format. Good. It then goes on to describe two such encoding mechanisms, the quoted-printable and Base64. Thus we can agree that Quoted-Printable and/or Base64 encoded data is in 7bit format. Now consider section 2.7 (definition of 7bit data), second sentence: "No octets with decimal values greater than 127 are allowed and neither are NULs (octets with decimal value 0). " By this definition, 7bit data must not include NUL data, that is an octet with decimal value 0. Now, if we look at the Base 64 vocabulary, we can see that a value of 52 is encoded as 0, which is in opposition to the sentence above. The easy explanation for this, which does seem to make more sense now that I think about it, is that the Base64 vocabulary does not include octets, instead, it has sixtets converted into textual characters. However, the nagging doubt with this is, that a 0 in an octet, is the same as a 0 in a sixtet. Comments? -- Vikram --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
