[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: Last Call: 'The Base16, Base32,
From:       Simon Josefsson <jas () extundo ! com>
Date:       2006-04-17 17:47:42
Message-ID: 873bgcm6v5.fsf () latte ! josefsson ! org
[Download RAW message or body]

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

Cullen Jennings <fluffy@cisco.com> writes:

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

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.

> 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 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,
> could we just remove it.

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

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

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.

> 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?

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

> Cullen
>
> On 4/3/06 6:29 AM, "The IESG" <iesg-secretary@ietf.org> 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
>> iesg@ietf.org or ietf@ietf.org 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
>> IETF-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]