2006/5/19, Paul Hoffman <[EMAIL PROTECTED]>:
At 1:58 AM +0200 5/19/06, Robert Sayre wrote:
>On 5/19/06, Lisa Dusseault <[EMAIL PROTECTED]> wrote:
>>
>>This announcement is for a document that will obsolete RFC3548, which is
>>referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax
>>(RFC4287).
>
>Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for
>a revision.
I'm confused. What breaks?
+1
base32 and base32hex are for use in case insensitive contexts, but XML
is case sensitive and Atom is XML.
I can't find a real need for base16 and it doubles the size of the
input, I'd say that Atom doesn't need it.
Atom doesn't need base64url either, as + and / are not reserved
characters in XML PCDATA (the only part of Atom where base64 is used).
base64url might be useful on "data" URL though, but that's not the use
of base64 encoding made by Atom.
There's no reason for Atom not to support those encodings (other than
because it introduces new encodings for processors to know about, and
it would introduce a new attribute to tell processors which encoding
has been used), but there's no reason for Atom to support any baseNN
encoding other than the "plain old" base64.
Having a single encoding is better for interop: implementors of
processors/producers know exactly what to support; supporting multiple
encodings would require an additional attribute telling which encoding
has been used, which would lead to complains that this attribute's
value set isn't extensible…
So no, Atom shouldn't have to support other baseNN encodings than
base64, and doing so wouldn't prove good for interop, so this revised
RFC doesn't break Atom.
--
Thomas Broyer
