One document matched: draft-josefsson-rfc4648-impl-report-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY RFC989 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0989.xml'>
    <!ENTITY RFC2045 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
    <!ENTITY RFC2938 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2938.xml'>
    <!ENTITY RFC4648 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'>
    <!ENTITY RFC5155 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml'>
    <!ENTITY GS2 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-gs2.xml'>
    <!ENTITY IMPLREPORT PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dusseault-impl-reports.xml'>
]>

<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="info" ipr="trust200902"
     docName="draft-josefsson-rfc4648-impl-report-00">

<front>

  <title>
    RFC 4648 Implementation Report
  </title>

<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
	<organization>SJD AB</organization>
	<address>
		<email>simon@josefsson.org</email>
	</address>
</author>
	
<date month="May" year="2009"/>

<abstract>

  <t>This is an implementation report of RFC4648, for the purpose of
    advancing the document to Draft Standard.</t>

  <t>See <http://josefsson.org/base-encoding/> for more
    information.</t>

</abstract>

</front>
	
<middle>

<section title="Introduction">

  <t>This is an implementation report of <xref target="RFC4648">The
    Base16, Base32, and Base64 Data Encodings</xref> document.  It
    follows the outline suggested by
    <xref target='I-D.dusseault-impl-reports' />.</t>

</section>

<section title="Summary">

  <t>The "base64" encoding have a long history of being used in
    Internet protocols, the earliest use in the RFC series appears to
    be <xref target="RFC0989"/>.  It has been widely implemented as
    part of MIME <xref target="RFC2045"/>, which is already a Draft
    Standard.  The "base64url" alphabet does not appear to be widely
    deployed.</t>

  <t>The "base32" encoding is not as widely used as base64, but has
    applications in the case insensitive systems.  The "base32"
    encoding is used by <xref target='I-D.ietf-sasl-gs2' />.  The
    "base32hex" encoding is used by <xref target="RFC5155"/>, and a
    restricted form is used by <xref target="RFC2938"/>.</t>

  <t>The "base16" encoding is usually referred to as hexadecimal, or
    hex encoding, and is used in many protocols and informally in
    technical documents.</t>

</section>

<section title="Methodology">

  <t>We identified that we wanted to test the following encodings:
    base64, base64url, base32, base32hex, base16.</t>

  <t>The primary test is of course that basic encoding and decoding
    works and lead to expected results.</t>

  <t>Section 3 of RFC 4648 discuss some implementation discrepancies
    of base encoding.  To possibly find interoperability problems, we
    checked and documented these corner-cases separately.  In
    particular: how line feeds are handled during encoding and
    decoding [LF], whether padding is done correctly [PAD], how
    non-alphabetical characters are handled [NONALPHA], whether pad
    bits are zero or not [ZEROBITS].</t>

  <t>A useful test case whether pad bit handling is appropriate is
    "YR==" which is a non-canonical encoding of "a" (ASCII 0x61) that
    normally is encoded as "YQ==".</t>

</section>

<section title="Exceptions">

  <t>Encoding and decoding of data interoperate well.</t>

  <t>Some tools accepted non-canonical encodings, but none appeared to
    ever generate them.  This is consistent with the requirements in
    section 3.5 of RFC 4648.</t>

  <t>We acknowledge that many implementations of base64 were written
    for a general purpose, and thus may not follow some of the
    guidelines (e.g., related to line feeds) in RFC 4648 strictly.
    However we believe this should not be a reason against Draft
    Standard status because the document is clear on the issues and
    the minor variations does not appear to lead to any problem.</t>

</section>

<section title="Implementations Tested">

  <section title="GNU Coreutils: base64">

    <t>There is a "base64" command line tool, written in C, included
      in GNU Coreutils <xref target="GNU-Coreutils-Base64"/>.  It
      supports the "base64" alphabet.</t>

    <t>[LF]: On encoding, it wraps output after 76 characters (same as
      MIME).  On decoding, it accepts line-wrapped input.</t>

    <t>[PAD]: It appears to pad data properly.</t>

    <t>[NONALPHA]: It appears to return a non-zero error code if the
      input contains non-alphabetical characters.</t>

    <t>[ZEROBITS]: On encoding, the pad bits are zero.  On decoding,
      it appears to accept non-zero pad bits.</t>

  </section>

</section>

<section title="Acknowledgements">

  <t>TBA</t>

</section>

<section title="Security Considerations">

  <t>See RFC 4648 for security considerations.</t>

</section>

<section title="IANA Considerations">

  <t>This document has no actions for IANA.</t>

</section>

</middle>

<back>

<references title="Normative References">
  &RFC4648;
</references>

<references title="Informative References">

  &IMPLREPORT;

  &RFC989;
  &RFC2045;
  &RFC2938;
  &RFC5155;

  &GS2;

   <reference anchor="GNU-Coreutils-Base64">
     <front>
       <title>GNU Coreutils "base64" tool version 7.2</title>
       <author initials="S" surname="Josefsson">
	 <organization></organization>
       </author>
       <date month="May" year="2009"/>
     </front>
     <seriesInfo name="WWW"
		 value="http://www.gnu.org/software/coreutils/"/>
   </reference>

</references>

</back>

</rfc>