[Codec] RFC2045 Anomaly?

[Vikram Goyal <te...@craftbits.com>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Codec] RFC2045 Anomaly?

[Oliver Geisser <ol...@gmx.de>]

Hi

Vikram Goyal wrote:

[...]
> 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.
[...]

You confuse the character "0" with the octet value 0.

What is BASE64?
A method of encoding binary data within text.
The way it works is that every three 8-bit bytes are stored in four 
6-bit characters, where the characters are in the range 
[A-Z][a-z][0-9][+/]. (Count 'em up; that's 64 total characters). Since 
this doesn't exactly line up, pad characters of [=] are used at the very 
end.

Hope this helps.

--og



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [Codec] RFC2045 Anomaly?

[Tim O'Brien <to...@discursive.com>]

Vikram Goyal wrote:

>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.
>
>  
>
If you look on page 25 of RFC 2045 (Nov 1996), Value 52 is encoded as 
character '0' which is 48. 

lookUpBase64Alphabet[52] = 48, and (char) 48 = '0'

Tim




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org