Subject: Fwd: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 May 2006 16:15:05 -0700

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).

There are also a few drafts that reference RFC3548 that caught my eye:

  - draft-ietf-nntpext-base, which is in RFC ED queue
  -  draft-josefsson-sasl-gs2-00
  - draft-otis-dkim-options-00
  - draft-snell-atompub-author-extensions-00

thanks,
Lisa

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: May 18, 2006 7:51:48 AM PDT
> To: IETF-Announce <[email-masked]>
> Cc: Internet Architecture Board <[email-masked]>, RFC Editor <rfc- 
> [email-masked]>
> Subject: Protocol Action: 'The Base16, Base32, and Base64 Data   
> Encodings' to Proposed Standard
>
> The IESG has approved the following document:
>
> - 'The Base16, Base32, and Base64 Data Encodings '
>    <draft-josefsson-rfc3548bis-04.txt> as a Proposed Standard
>
> This document has been reviewed in the IETF but is not the product  
> of an
> IETF Working Group.
>
> The IESG contact person is Ted Hardie.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-04.txt
>
> Technical Summary
>
>   This document describes the commonly used base 64, base 32, and base
>    16 encoding schemes.  It also discusses the use of line-feeds in
>    encoded data, use of padding in encoded data, use of non-alphabet
>    characters in encoded data, and use of different encoding  
> alphabets.
>    It obsoletes the descriptions in RFC 3548.
>
> Working Group Summary
>
>  This work is the product of an individual submitter.  There were  
> significant
>  IETF Last Call comments, and the draft was updated to respond to  
> them.
>
> Protocol Quality
>
>  This document was reviewed for the IESG by Ted Hardie.
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 19 May 2006 01:58:33 +0200

On 5/19/06, Lisa Dusseault <[email-masked]> 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.

>  - draft-snell-atompub-author-extensions-00

Oh, this excellent document is affected too. Seems like we have a real
problem here.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 May 2006 18:02:31 -0700

>Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for

I'm confused. What breaks?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Joe Gregorio" <[email-masked]>
Date: Thu, 18 May 2006 23:13:03 -0400

I think Robert is referring to this:

   http://tinyurl.com/l2uop

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: "James Holderness" <[email-masked]>
Date: Fri, 19 May 2006 04:38:40 +0100

In which you predict somebody will *complain* that Atom is broken - you 
never claim that Atom will actually break. I think Robert's complaint is 
merely a kind attempt to help you fulfil your prophecy.

---

From: "Thomas Broyer" <[email-masked]>
Date: Fri, 19 May 2006 08:51:26 +0200

> 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