RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

RFC 4130, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", July 2005

Source of RFC: ediint (app)

Errata ID: 3028
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12

Section 7.4.3 says:

   digest-alg-id = "sha1" | "md5"

It should say:

   digest-alg-id = "sha-1" | "sha1" | "md5"
		; The "sha1" is a legacy spelling of the "sha-1" defined hash in the IANA Textual Names Registry
		; It should be maintained for backwards compatibility

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility. The other hashes are newer ones since the RFC was published.
--VERIFIER NOTES--
Split off erratum 1974

Errata ID: 3029
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kyle Meadors
Date Reported: 2011-09-16
Verifier Name: Pete Resnick
Date Verified: 2011-11-12

Section 7.3 says:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------
         SHA-1        sha1
         MD5          md5

It should say:

   The currently supported values for MIC algorithm <micalg> values are:

        Algorithm   Value Used
        ---------    -------

         SHA-1      sha-1 or sha1
         MD5        md5

Notes:

The proper spelling is "sha-1" per http://www.iana.org/assignments/hash-function-text-names/hash-function-text. However, "sha1" should still be accepted to support backwards compatibility.

Errata ID: 1575
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: r. deutsch
Date Reported: 2008-10-14
Verifier Name: Alexey Melnikov
Date Verified: 2010-05-20

Section 4.1 says:

Any difference between AS2 implantations and RFCs are
                           ^^^^^^^^^^^^^
   mentioned specifically in the sections below.

It should say:

Any difference between AS2 implementations and RFCs are
                           ^^^^^^^^^^^^^^^
   mentioned specifically in the sections below.

Notes:

The word "implantations" should be "implementations".

Errata ID: 4743
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Joe Touch
Date Reported: 2016-07-15
Verifier Name: Orie Steele
Date Verified: 2024-03-29

Section A.3, A.4 says:

A.3.  Signed, Encrypted Message Requesting a Signed, Asynchronous
      Receipt

   Message-ID: <#as2_company#01#a4260as2_companyout#>
   Date: Thu, 19 Dec 2002 15:04:18 GMT
   From: me@example.com
   Subject: Async MDN request
   Mime-Version: 1.0
   Content-Type: application/pkcs7-mime;
     smime-type=enveloped-data; name=smime.p7m
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename=smime.p7m
   Recipient-Address: 10.240.1.2//
   Disposition-Notification-To:
     http://10.240.1.2:8201/exchange/as2_company
   Disposition-Notification-Options: signed-receipt-protocol=optional,
    pkcs7-signature; signed-receipt-micalg=optional,sha1
   Receipt-Delivery-Option:
     http://10.240.1.2:8201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.1
   Host: 10.240.1.2:8101
   Connection: close
   Content-Length: 3428

     [omitted binary encrypted data]



Moberg & Drummond           Standards Track                    [Page 44]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


A.4.  Asynchronous MDN for Message A.3, Above

   POST / HTTP/1.1
   Host: 10.240.1.2:8201
   Connection: close, TE
   TE: trailers, deflate, gzip, compress
   User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
   Date: Thu, 19 Dec 2002 15:03:38 GMT
   Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
   AS2-Version: 1.1
   Mime-Version: 1.0
   Recipient-Address:
   http://10.240.1.2:8201/exchange/as2_company
   AS2-To: as2_company
   AS2-From: "AS2 Test"
   Subject: Your Requested MDN Response
   From: as2debug@example.com
   Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
   Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature";
     boundary="----=_Part_337_6452266.1040310218750"
   Content-Length: 3103

   ------=_Part_337_6452266.1040310218750
   Content-Type: multipart/report;
     report-type=disposition-notification;
     boundary="----=_Part_336_6069110.1040310218718"

   ------=_Part_336_6069110.1040310218718
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
   2002 15:04:18 GMT with Subject <async MDN request> has been received.
   The EDI Interchange was successfully decrypted, and its integrity was
   verified.  In addition, the sender of the message, Sender
   <as2_company> at Location http://10.240.1.2:8201/exchange/as2_company
   was authenticated as the originator of the message.  There is no
   guarantee, however, that the EDI interchange was syntactically
   correct, or that it was received by the EDI application/translator.











Moberg & Drummond           Standards Track                    [Page 45]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


   ------=_Part_336_6069110.1040310218718
   Content-Type: message/disposition-notification
   Content-Transfer-Encoding: 7bit

   Reporting-UA: AS2@test:8101
   Original-Recipient: rfc822; "AS2 Test"
   Final-Recipient: rfc822; "AS2 Test"
   Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
   Disposition: automatic-action/MDN-sent-automatically;
     processed
   Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1

   ------=_Part_336_6069110.1040310218718--

   ------=_Part_337_6452266.1040310218750
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
   4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
   UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=

   ------=_Part_337_6452266.1040310218750-

It should say:

A.3.  Signed, Encrypted Message Requesting a Signed, Asynchronous
      Receipt

   Message-ID: <#as2_company#01#a4260as2_companyout#>
   Date: Thu, 19 Dec 2002 15:04:18 GMT
   From: me@example.com
   Subject: Async MDN request
   Mime-Version: 1.0
   Content-Type: application/pkcs7-mime;
     smime-type=enveloped-data; name=smime.p7m
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment; filename=smime.p7m
   Recipient-Address: 10.240.1.2//
   Disposition-Notification-To:
     http://10.240.1.2:58201/exchange/as2_company
   Disposition-Notification-Options: signed-receipt-protocol=optional,
    pkcs7-signature; signed-receipt-micalg=optional,sha1
   Receipt-Delivery-Option:
     http://10.240.1.2:58201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.1
   Host: 10.240.1.2:58101
   Connection: close
   Content-Length: 3428

     [omitted binary encrypted data]



Moberg & Drummond           Standards Track                    [Page 44]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


A.4.  Asynchronous MDN for Message A.3, Above

   POST / HTTP/1.1
   Host: 10.240.1.2:58201
   Connection: close, TE
   TE: trailers, deflate, gzip, compress
   User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
   Date: Thu, 19 Dec 2002 15:03:38 GMT
   Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
   AS2-Version: 1.1
   Mime-Version: 1.0
   Recipient-Address:
   http://10.240.1.2:58201/exchange/as2_company
   AS2-To: as2_company
   AS2-From: "AS2 Test"
   Subject: Your Requested MDN Response
   From: as2debug@example.com
   Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
   Content-Type: multipart/signed; micalg=sha1;
     protocol="application/pkcs7-signature";
     boundary="----=_Part_337_6452266.1040310218750"
   Content-Length: 3103

   ------=_Part_337_6452266.1040310218750
   Content-Type: multipart/report;
     report-type=disposition-notification;
     boundary="----=_Part_336_6069110.1040310218718"

   ------=_Part_336_6069110.1040310218718
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
   2002 15:04:18 GMT with Subject <async MDN request> has been received.
   The EDI Interchange was successfully decrypted, and its integrity was
   verified.  In addition, the sender of the message, Sender
   <as2_company> at Location 
   http://10.240.1.2:58201/exchange/as2_company
   was authenticated as the originator of the message.  There is no
   guarantee, however, that the EDI interchange was syntactically
   correct, or that it was received by the EDI application/translator.











Moberg & Drummond           Standards Track                    [Page 45]

RFC 4130     AS2 for Business Data Interchange Using HTTP      July 2005


   ------=_Part_336_6069110.1040310218718
   Content-Type: message/disposition-notification
   Content-Transfer-Encoding: 7bit

   Reporting-UA: AS2@test:58101
   Original-Recipient: rfc822; "AS2 Test"
   Final-Recipient: rfc822; "AS2 Test"
   Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
   Disposition: automatic-action/MDN-sent-automatically;
     processed
   Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1

   ------=_Part_336_6069110.1040310218718--

   ------=_Part_337_6452266.1040310218750
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s

   BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
   4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
   UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=

   ------=_Part_337_6452266.1040310218750-

Notes:

Port numbers used in examples need to either refer to the intended service (e.g., 80 for HTTP) or use dynamic ports (49152-65535). The examples provided used examples in the assigned User ports range (8101, 8201) both as source and destination, and neither is appropriate for the example service described.

The simplest change was to add a "5" in front of the numbers, placing them in the dynamic range (e.g., 58101, 58201).

Report New Errata



Advanced Search