PIP 0A1 — Notification of Failure

RosettaNet choreography in cluster 0 (RosettaNet Support), covering the XML exchange between Failure Notifier ↔ Failure Recipient. Operational unit for rosettanet support on RNIF V02.00.

PIP purpose

PIP 0A1 carries a notification of application or processing failure: a partner signals to another, or to a trusted operator, that a previously exchanged PIP could not be processed (invalid signature, malformed content, broken choreography). It serves as an out-of-band complement to the RNIF Exception mechanism when the issue is detected at the business level rather than at the envelope level.

Message structure

The 0A1 choreography follows the one-action (notification) RosettaNet model:

• Action: Failure Notification Action
• Signal: Receipt Acknowledgment

Each action is wrapped in a multipart MIME RNIF V02.00 envelope signed with S/MIME. Here is a condensed view of the envelope:

MIME-Version: 1.0
Content-Type: multipart/related; type="application/xml";
  boundary="RN-BOUNDARY-2026"

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-Preamble.xml

<Preamble xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <standardName>RosettaNet</standardName>
  <standardVersion>V02.00</standardVersion>
</Preamble>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-ServiceHeader.xml

<ServiceHeader xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <GlobalProcessIndicatorCode>0A1</GlobalProcessIndicatorCode>
</ServiceHeader>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: Pip0A1FailureNotification.xml

<!-- payload PIP 0A1 ci-dessus -->

--RN-BOUNDARY-2026--

Simplified XML example

Minimal PIP 0A1 payload for didactic purposes. The structural elements (fromRole, toRole, thisDocumentGenerationDateTime, and the PIP-specific business block) are required in any conformant implementation.

<?xml version="1.0" encoding="UTF-8"?>
<Pip0A1FailureNotification xmlns="http://www.rosettanet.org/PIP0A1">
  <fromRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>FailureNotifier</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </fromRole>
  <toRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>FailureRecipient</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </toRole>
  <thisDocumentGenerationDateTime>
    <DateTimeStamp>20260515T101500Z</DateTimeStamp>
  </thisDocumentGenerationDateTime>
      <FailureType>
        <GlobalFailureTypeCode>Choreography</GlobalFailureTypeCode>
      </FailureType>
      <FailureReason>
        <FreeFormText>PIP3A4 message ID PO-2026-987654 rejected: invalid SHA-256 signature</FreeFormText>
      </FailureReason>
      <ReferenceTrackingID>PO-2026-987654-RN</ReferenceTrackingID>
</Pip0A1FailureNotification>

Transport and acknowledgment

Standard RNIF V02.00 transport over HTTPS (POST to the partner endpoint) or AS2. PIP 0A1 is typically sent best-effort, with no return signal, to avoid cascading error cycles.

The transport channel is typically AS2 or direct HTTPS (RNIF over HTTP). For a reference of the security layers in use, see the AS2 on ediverse page.

Use case

An OSAT (Outsourced Semiconductor Assembly and Test) receives a PIP 3A4 from TSMC, but the S/MIME signature fails verification. The OSAT emits a PIP 0A1 to the TSMC support service: target PO message, failure type Signature, detailed reason, tracking identifier for correlation.

Further reading

• RosettaNet Standards Programme — GS1 US — official PIP catalogue.
• RosettaNet PIP Catalog (web.archive.org) — historical version of the rosettanet.org catalogue before its 2013 retirement.
• RosettaNet — hub on ediverse — overview, PIP / RNIF architecture, and clusters.
• AS2 on ediverse — alternative transport compatible with RNIF.