Hi Cullen, thanks for your review! Sorry for the delay in answering
this, I was on vacation.
Cullen Jennings <fluffy(_at_)cisco(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf