RosettaNet PIP Validator (RNIF 2.0)

Validate a RosettaNet RNIF 2.0 envelope (multipart/related, Preamble + ServiceHeader + ServiceContent) or a bare ServiceContent XML. 50 PIPs recognised, from PIP3A4 PurchaseOrderRequest to PIP7B5 ManufacturingWorkOrder.

How it works

RosettaNet is the global B2B standard for the electronics / semiconductor supply chain, deployed at Intel, TSMC, Samsung, Sony, Cisco, Lenovo, Foxconn, ASML and most of the high-tech chain. The standard is hosted by GS1 US today and still runs in production on mission-critical PIPs (Partner Interface Processes).

The RNIF 2.0 transport (RosettaNet Implementation Framework) wraps each message inside a multipart/related envelope with three XML parts:

• Preamble: GlobalAdministeringAuthorityCode, GlobalUsageCode (Test / Production), ProcessInstanceIdentifier and version.
• ServiceHeader: pipCode, pipVersion, actionInfo, fromRole / toRole, fromPartner / toPartner with authority (DUNS / GLN / EAN / UPC).
• ServiceContent: the business document itself, whose root element name encodes the PIP (Pip3A4PurchaseOrderRequest, Pip3B12ShipmentNotification…).

Validator pipeline:

1. Auto-detect: full RNIF envelope or bare ServiceContent XML.
2. Split multipart/related, identify parts by their Content-ID, then fall back to the XML root element name.
3. XML parsing per part, validation of mandatory fields.
4. pipCode recognition against the bundled catalogue, cluster lookup, action and version reporting.
5. Structured diagnostics with stable codes and severities.

Rules checked

• Envelope: Content-Type: multipart/related with a mandatory boundary parameter. A different type raises E_NOT_MULTIPART; a missing boundary raises E_NO_BOUNDARY.
• XML parts: Preamble, ServiceHeader and ServiceContent are mandatory. Their absence raises E_NO_PREAMBLE, E_NO_SERVICE_HEADER and E_NO_SERVICE_CONTENT respectively.
• GlobalUsageCode: must be Test or Production. Any other value raises E_INVALID_USAGE_CODE.
• GlobalAdministeringAuthorityCode: the canonical value is RosettaNet. A different authority raises W_UNEXPECTED_AUTHORITY.
• Signal kind: Action, Signal, ReceiptAcknowledgement or ReceiptAcknowledgementException. Parsed from the SignalKind element when present, defaulting to Action.
• pipCode: must match cluster (0-7) + segment (letter) + serial (digits), e.g. 3A4, 3B12, 7B5. A well-formed code that is not in the bundled catalogue raises E_UNKNOWN_PIP; a recognised code emits the info I_PIP_RECOGNIZED.
• Partner authority: DUNS, GLN, EAN or UPC. An unknown authority raises W_UNKNOWN_AUTHORITY.
• Attachments: missing attachments raise W_NO_ATTACHMENTS. Attachments are identified by their Content-ID and Content-Type.
• S/MIME signature: a missing application/pkcs7-signature part raises W_MISSING_SIGNATURE. The signature itself is not cryptographically verified.

PIP clusters

The 200+ PIPs published by RosettaNet are organised in eight clusters. The cluster digit immediately tells you the functional domain of a pipCode:

Bundled PIP catalogue (53)

Exhaustive list of PIPs recognised by the validator. For each PIP: the code, the version, the direction (Action / Signal) and the bilingual description sourced from the GS1 US PIP Directory.

Limits

• No full XSD validation of the ServiceContent body. The validator recognises the root and action, but does not validate the per-PIP business fields. PIP3A4 for example does not have its PurchaseOrderLineItem completeness checked.
• No cryptographic verification of the S/MIME signature. The validator reports its presence and type, but does not recompute the digest.
• No re-emission of the ReceiptAcknowledgement the partner would expect — this is a passive inspection tool.
• No support for RNIF 1.1 nor ebMS-over-RNIF hybrid extensions.

Privacy

Related documentation

• GS1 US — RosettaNet Standards Library — the official entry point of the standard since the GS1 US acquisition.
• RNIF Core Standards — the RNIF 2.0 specification itself (Preamble, ServiceHeader, transport).
• RosettaNet standard — overview — what the clusters, segments and PIP nomenclature actually cover.
• PEPPOL SBDH Validator — the PEPPOL-side equivalent XML envelope.