Subject: Re: Last Call: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2006 16:12:50 -0700

There seems to be two (or more) common base 64 encoding alphabets. Could we
enumerate the alphabets used in at least standards track RFCs and give each
one a more specific name so that specification could specify which one the
forms was used. This might help implementers understand there were multiple
forms and libraries might provide a flag to choose the correct one.

Has the filename safe version of base64 been used anywhere - if so can we
provide a better reference and a post to a mailing list? If not can we
remove it?

I was wondering if this form of Base32 was actually used anywhere. If not,
could we just remove it.

Did the base32 extended hex version get used in the SASL work? Can we update
the reference or if it is not needed not just remove it.

Having LGPL code in the draft will no doubt cause concerns for some people -
given the simplicity in understanding this algorithm and wide availability
of working code, does having this code here really improve the
specification?

Cullen

On 4/3/06 6:29 AM, "The IESG" <[email-masked]> wrote:

> The IESG has received a request from an individual submitter to consider the
> following document:
> 
> - 'The Base16, Base32, and Base64 Data Encodings '
>    <draft-josefsson-rfc3548bis-02.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-05-01.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-02.txt
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Apr 2006 09:31:52 +1000

> the reference or if it is not needed not just remove it.

	base32 extended hex is being / will be used for NSEC3 as it
	preserves the sort order.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2006 18:14:07 -0700

> preserves the sort order.

Great - perhaps we could add a reference to that.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Apr 2006 11:26:11 +1000

> Great - perhaps we could add a reference to that. 

	Work in progress. draft-ietf-dnsext-nsec3-04.txt needs to
	be update to say base32 extended hex and reference this
	draft.

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Apr 2006 21:34:05 -0400

--On Tuesday, 11 April, 2006 11:26 +1000 Mark Andrews
<[email-masked]> wrote:

>> >> Did the base32 extended hex version get used in the SASL
>> >> work? Can we upda
>> te

But such a reference from the Base16, Base32,... draft is not
normative.  To simply give (clearly non-normative) examples,
with each encoding, of where it is used or expected to be used
seems to me to helpful to the reader and to cost almost nothing.

    john

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Apr 2006 12:46:13 -0700

> seems to me to helpful to the reader and to cost almost nothing.

I was concerned that we might be defining an option that no one needed and
that would just encourage more variations where they were not needed. The
fact that nsec3 has chosen to use this particular form is good enough proof
for me that there is a need for the base32 extended hex form. I agree a
informative ref to the work in progress will help people fine examples of
where it was used and perhaps have a better understanding of where and why
they might pick a particular form. All sounds good.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Apr 2006 19:28:53 +0200

> they might pick a particular form. All sounds good.

I agree with this discussion, and have added an informational
reference to the NSEC3 document in the base32hex section.  The updated
version can be found at:

http://josefsson.org/base-encoding/draft-josefsson-rfc3548bis.txt

with rfcdiff's to the -02 version in last call at:

http://josefsson.org/base-encoding/draft-josefsson-rfc3548bis-from--02.diff.html

Thanks.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Apr 2006 19:47:42 +0200

Hi Cullen, thanks for your review!  Sorry for the delay in answering
this, I was on vacation.

> forms and libraries might provide a flag to choose the correct one.

That seems like a good idea.  I'm not sure this document is the best
place for it, but it may be.  If you want to see this added, please
suggest text for a new section with this information.

> provide a better reference and a post to a mailing list? If not can we

I don't know.  I recall a request to add a filename safe alphabet to
RFC 3548, probably in a last call comment, and while digging up the
background on that, the only reference I could find was that mailing
list post.

> I was wondering if this form of Base32 was actually used anywhere. If not,

I don't know.  A survey of standards referencing this document may
answer that.

> the reference or if it is not needed not just remove it.

The SASL GS2 work is using base32, but which alphabet is not crucial.
We could request to have the alphabet in GS2 changed.

The reference is there to document from where the alphabet came, if I
update it to point at the current document (which point at
rfc3548bis), some information is lost.  I could add an extra reference
to the current version of that document though.

> of working code, does having this code here really improve the

Several people has requested code.  Note that several existing
implementations are broken, in particular in the handling of
non-alphabet characters, excessive padding, and handling prematurely
terminated inputs.  Eventually I wrote my own, partially based on one
with clean design.

Thanks,
Simon