OASIS ebCore Party Id Type Technical Specification Version 1.0

Committee Draft 02

02 April 2010

Specification URIs:

This Version:

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/CD02/PartyIdType-1.0.odt  (Authoritative)

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/CD02/PartyIdType-1.0.html

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/CD02/PartyIdType-1.0.pdf

Previous Version:

N/A

Latest Version:

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.odt (Authoritative)

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.html

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.pdf

Technical Committee:

OASIS ebXML Core (ebCore) TC

Chair(s):

Dale Moberg, Axway.

Kathryn Breininger, The Boeing Company.

Editor(s):

Dale Moberg, Axway.

Pim van der Eijk, Sonnenglanz Consulting.

Related Work:

This specification is related to:

Declared XML Namespace(s):

urn:oasis:names:tc:ebcore:partyid-type

urn:oasis:names:tc:ebcore:partyid-type:iso6523

urn:oasis:names:tc:ebcore:partyid-type:iso9735

urn:oasis:names:tc:ebcore:partyid-type:iso20022

urn:oasis:names:tc:ebcore:partyid-type:unregistered
urn:oasis:names:tc:ebxml-cppa:partyid-type

Abstract:

A mechanism for the identification of business partners in XML business documents and XML message headers based on URN-based identifier types is required in many electronic business exchanges. This specification specifies a formal URN-based mechanism for referencing party types from the ISO 6523, ISO 9735 and ISO 20022 identification scheme catalogs using the oasis URN namespace. Sample applications include (but are not limited to): ebXML message headers; ebXML collaboration protocol profiles and agreements; UBL, UN/CEFACT and OAGIS XML business documents; and the UN/CEFACT SBDH.

Status:

This document was last revised or approved by the OASIS ebXML Core (ebCore) TC on the above date. The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ebcore.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ebcore/ipr.php).

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/ebcore/.

Notices

Copyright © OASIS® 2010. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS"  is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

Table of Contents

1 Introduction5

1.1 Terminology5

1.2 Normative References6

1.3 Non-normative References6

2  OASIS ebCore PartyId Type 8

2.1 URN Syntax for PartyId Type 8

2.2 ISO 65238

2.3 ISO 97359

2.4 ISO 20022 Data Source Schemes10

2.5 Unregistered10

2.6 Compatibility URN ebxml-cppa:partyid-type 10

3 Sample Applications12

3.1 ebXML Collaboration Protocol Profiles and Agreements (CPPA)12

3.2 ebXML Messaging (ebMS)12

3.3 Universal Business Language (UBL)12

3.4 UN/CEFACT XML Schemas and OAGIS13

3.5 UN/CEFACT Standard Business Document Header (SBDH)13

4 Conformance14

Appendix A.Acknowledgments15

 

1 Introduction

Several schemes exist for naming identifier domains. For example, the GS1 organizations assign Global Location Numbers ([GLN]) to identify physical locations and legal entities to improve the efficiency of communication with the supply-chain. The GLN is the basis for the Global GS1 Electronic Party Information Registry [GEPIR]. Other well-known directories include D-U-N-S (Dun and Bradstreet), national Chamber of Commerce registries, and financial industry identification schemes.

ISO 6523, ISO 9735 and ISO 20022 serve as "catalogs" of schemes for naming identifier domains; processes exist by which additional domains can be identified through the Registration Authorities (RA):

These three identification schemes are not URN-based. A requirement in many electronic business communities is to have a mechanism for identification of business partners in XML business documents, document headers and XML message headers based on Universal Resource Names (URNs). This specification specifies a formal mechanism for referencing party type identification schemes using a formal URN notation that leverages these three identification scheme catalogs. This allows these existing schemes to be reused using an alternative URN-based syntax, without duplication of Registration Authorities.  The references to OASIS and to the ebCore Technical Committee just serve to support the formation of URN-based identifiers and do not establish OASIS or the ebCore TC themselves as PartyId Registration Authorities. This specification also provides a fourth formal URN prefix for unregistered (mutually agreed) party identification and a URN for backwards compatibility with a previous draft version of this specification developed in the former ebXML CPP/CPA TC, which is used in some business communities.

With the exception of the ISO 6523 scheme (which allows some other notations for compatibility) and the CPP/CPA backwards compatibility format, the general format of the proposed URN is:

urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-in-catalog

Future revisions of this specification may recognize catalog-identifier identifiers for catalogs other than ISO 6523, ISO 9735 and ISO 20022. For flexibility, this specification already offers unlimited extensibility through the unregistered scheme (defined in 2.5 ).

As an illustration, this specification also contains a non-normative section that describes some sample applications:

1.1 Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119].

1.2 Normative References

[URN-NS]IANA. Uniform Resource Names (URN) Namespaces.
http://www.iana.org/assignments/urn-namespaces/

[ISO6523-1] ISO/IEC 6523-1:1998. Information technology -- Structure for the identification of organizations and organization parts -- Part 1: Identification of organization identification schemes.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=25773

[ISO9735]ISO 9735:1988. Electronic data interchange for administration, commerce and transport (EDIFACT) -- Application level syntax rules.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=17592

[RFC 2119]S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force (IETF) RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119.txt.

[RFC2141] URN Syntax, Internet Engineering Task Force (IETF) RFC 2141, May 1997.
http://www.ietf.org/rfc/rfc2141.txt.

[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax, Internet Engineering Task Force (IETF) RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt.

[RFC3121]K. Best. A URN Namespace for OASIS.
http://www.ietf.org/rfc/rfc3121.txt.

[RFC3406]L. Daigle. Uniform Resource Names (URN) Namespace Definition Mechanisms. Oktober 2002.
http://www.ietf.org/rfc/rfc3406.txt.

 

1.3 Non-normative References

[CWA16036]Cyber-Identity - Unique Identification Systems For Organizations and Parts Thereof. CEN Workshop Agreement 16036. November 2009.
ftp://cenftp1.cenorm.be/PUBLIC/CWAs/Cyber_Identity/CWA_CyberIdentity.pdf.

[DUNS]Dun & Bradstreet D-U-N-S Number.
http://www.dnb.com/us/.

[ebCPPA]OASIS Standard, “Collaboration-Protocol Profile and Agreement Specification Version 2.0”, November 2002.
http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf

[EBMS2]OASIS Standard, “Message Service Specification Version 2.0”, August 2002.
http://www.oasis-open.org/specs/#ebxmlmsgv2

[EBMS3CORE]OASIS Standard,”OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features”, October 2007.
http://www.oasis-open.org/specs/#ebxmlmsgv3

[GEPIR]The Global GS1 Electronic Party Information Registry.
http://gepir.gs1.org/.

[GLN]GS1 Global Location Number (GLN).
http://www.gs1.org/barcodes/technical/idkeys/gln

[OAGIS]Open Applications Group. Integration Specification 9.4 (OAGIS).
http://www.oagi.org/.

[SBDH]UN/CEFACT ATG. “Standard Business Document Header (SBDH)”. http://www.gs1.org/gsmp/kc/ecom/xml/xml_sbdh

[UBL2]OASIS Standard, “Universal Business Language v2.0”, December 2006.
http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html.  

[UNCEFACT]UN/CEFACT XML Schemas, release D09A.
http://www.unece.org/cefact/xml_schemas/index.htm#2009A.  

 

 

 

 

2  OASIS ebCore PartyId Type

This section defines the ebCore PartyId Type.

2.1 URN Syntax for PartyId Type

The concept of Universal Resource Identifier (URI) and Universal Resource Name (URN) are defined in the Internet Engineering Task Force (IETF) [RFC2396] and [RFC2141] specifications. General definitions of, and mechanisms for, establishing Uniform Resource Names (URN) "namespaces" are specified in [RFC3406]. The Internet Assigned Names Authority (IANA) acts as Registration Authority for URN namespaces. IANA supports a process for assigning formal Namespace IDs (NIDs) based on the IETF consensus process. NID application is made via publication of an RFC through standard IETF processes. A list of currently assigned NIDs is published on [URN-NS]. The assigned oasis NID is described in [RFC3121].

This specification uses the assigned oasis NID to establish formal URN-based references to party identification schemes based on the prefix:

urn:oasis:names:tc:ebcore:partyid-type:

This prefix is the basis for a standard mechanism for constructing URNs from the OASIS namespace ID that reference identifier schemes in identifier scheme catalogs. Specific support is provided for the ISO 6523, ISO 9735 and ISO 20022 catalogs. This specification does not replace or compete with any existing identification scheme authority. Rather, its purpose is to provide a valid formal URN prefix that allows the use of established standards for identification of parties in contexts where URN (or more generally URI) values are required.

This specification is based on previous work in the ebXML CPP/CPA Technical Committee. That work was based on user requirements and has since been deployed by e-business user communities. Section 2.6 of this specification provides a compatibility mode that supports this existing practice. For additional background and context on party identification schemes, also see [CWA16036].

2.2 ISO 6523

Several schemes exist for naming identifier domains. [ISO6523-1] enumerates values for many domains: the domain is identified by a four-digit numeric sequence for International Code Designators (ICDs). For example:

This section specifies a method to construct a URN to identify an identification scheme registered in [ISO6523-1].

If an abbreviated name is described in the item titled “Name of Coding System” within the ICD list, a type attribute can be constructed by prepending: urn:oasis:names:tc:ebcore:partyid-type: to the abbreviated name and appending a colon “:” followed by the ICD value. For example:

Value of the URN:

urn:oasis:names:tc:ebcore:partyid-type:D-U-N-SNumber:0060

Because an abbreviated name may be omitted from the ICD list, the type attribute can always contain the string derived from “Name of Coding System” expressed in upper-camel-case. A value can always be constructed by pre-pending urn:oasis:names:tc:ebcore:partyid-type: to the upper-camel-case name and appending a colon “:” followed by the ICD value. For example, using the formal name of the Name of Coding System: “Data Universal Numbering System”:

Transformed Camel-case: “DataUniversalNumberingSystem”

Value of the URN:

urn:oasis:names:tc:ebcore:partyid-type:DataUniversalNumberingSystem:0060

Punctuation marks in these formal names (such as, “/”, “-“ or “’” ) should be included unless they are not allowed in URNs [RFC2141]. If the punctuation characters are not allowed in URNs, then the hexadecimal escaping convention explained in [RFC2141] should be followed for characters not allowed in URNs. However, spaces are not allowed in URNs and should be consumed during the production of an upper-camel-case string, rather than preserved in an escaped form. Words in names that are all upper-case should remain so when converted to an upper-camel-case string.

The ICD value should be appended as the last field of the URN so that any collision between formal or abbreviated names is avoided.

Another example of the above schema is:

urn:oasis:names:tc:ebcore:partyid-type:StandardCompanyCode:0147

This example designates a partner identification code which is registered with the Japan Information Processing Development Corporation / Electronic Commerce Promotion Center (JIPDEC/ECPC).

Because an abbreviated name may be omitted from the ICD list, the URN value can always contain a string derived from “Name of Coding System” expressed in upper-camel-case. If this string is considered too lengthy, the string constant “iso6523” can be used instead. A value for the URN can then always be constructed by prepending urn:oasis:names:tc:ebcore:partyid-type: to either the string constant or the upper-camel-case name and appending a colon “:” followed by the ICD value.

For example, the identifier for “Data Universal Numbering System” can be transformed in either:

2.3 ISO 9735

Alternatively, the code list for ISO 9735 (UN/EDIFACT syntax) D.3 Service simple data element 0007 (Identification Code qualifier) can be used to name identifier domains [ISO9735].  The URN will be constructed using the prefix urn:oasis:names:tc:ebcore:partyid-type: followed by iso9738: followed by the specified code value. Since the value for GLN in this code list is 14, the constructed URN has the syntax:

urn:oasis:names:tc:ebcore:partyid-type:iso9738:14

Similarly, the D-U-N-S scheme has the value 1 in this code list, so it would be represented as:

urn:oasis:names:tc:ebcore:partyid-type:iso9738:1

The envisaged application of this scheme is the exchange of EDIFACT documents using an XML-based B2B message protocol, like ebXML Messaging.

2.4 ISO 20022 Data Source Schemes

The ISO 20022 universal financial industry message scheme has a concept called Data Source Schemes  (DSS) which allows an industry body to specify the use of a proprietary code list that is not owned nor managed by ISO 20022, and that replaces a standard code list in specific ISO 20022 Message Components, where the use of such DSS has been approved.  Data source issuers are identified using four character codes. For instance, XLON identifies “London Stock Exchange” and XETR identifies “Deutsche Boerse AG: XETRA (exchange electronic trading)”. In the specific context of ISO 20022 messages, the context will already indicate that such codes are to be interpreted as referring to approved ISO 20022 DSS schemes. In other contexts, the following prefix allows URN party type identification strings for to be constructed and interpreted in an unambiguous manner.

urn:oasis:names:tc:ebcore:partyid-type:iso20022:

An example identification scheme indentifier would be:

urn:oasis:names:tc:ebcore:partyid-type:iso20022:xlon

2.5 Unregistered

To support situations where there is a requirement to use a valid formal URN as partner identifier, but only an informal, mutually agreed or proprietary identification scheme is used, the following type is provided as a prefix.

urn:oasis:names:tc:ebcore:partyid-type:unregistered:

The unregistered scheme can be used as an extension element for Party Identification schemes that are not registered in the three catalogs recognized in this specification, for example:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:myscheme

It can also be used to identify scheme catalogs other than the three catalogs and a scheme in such a catalog, for example:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:mycatalog:myscheme

Presence of the substring unregistered: in this example clearly distinguishes unregistered catalogs like mycatalog from the established iso6523, iso9735 and iso20022 scheme catalogs, while offering unlimited extensibility.  

2.6 Compatibility URN ebxml-cppa:partyid-type

This specification is based on draft revisions of the 2.0 specification of ebXML Collaboration Protocols and Agreements and a draft revision of version 3.0. Recognizing that several implementations of the proposed mechanism exist in production use, which anticipated the standardization process, implementations SHOULD also support the following prefix, which was used in these draft documents:

urn:oasis:names:tc:ebxml-cppa:partyid-type:

Implementations MUST process these values as if the following prefix, defined in this specification, had been used:

urn:oasis:names:tc:ebcore:partyid-type:

Furthermore, to be consistent with version 2.0 of CPP/A, the value that follows SHOULD be accepted as a valid type party identification scheme URN:

urn:oasis:names:tc:ebxml-cppa:partyid-type:duns.

This value is equivalent to:

urn:oasis:names:tc:ebcore:partyid-type:iso6523:0060

and

urn:oasis:names:tc:ebcore:partyid-type:iso9738:1

3 Sample Applications

This non-normative section describes some applications of the PartyId-Type URN.

3.1 ebXML Collaboration Protocol Profiles and Agreements (CPPA)

The ebXML Collaboration Protocol Profiles and Agreements ([ebCPPA]) specification can use the proposed URN party identification type scheme. In a CPA, the PartyId specifies the identification of a party in the agreement. The @type attribute of this element has a type URI and defines a namespace for the value or content of the PartyId element. The type attribute can therefore use the URN-based identification of the identification system in which the party identification is to be interpreted. The following example show a fragment of a CPA that involves a entity identified using the code  4035811991021 in the GLN system.

<cpa2:PartyInfo tns:partyName="Example company"

       cpa2:defaultMshChannelId="P1_channel_"
      cpa2:defaultMshPackageId="DefaultPackage">

<cpa2:PartyId
       cpa2:type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"
           >4035811991021</cpa2:PartyId>

<cpa2:PartyRef xlink:href="http://www.example.com/"/>

<cpa2:CollaborationRole>
      ...

3.2 ebXML Messaging (ebMS)

The OASIS ebXML Messaging ([EBMS2], [EBMS3CORE]) specifications can similarly use the ebCore PartyId type. In an ebXML message, both the sender and recipient of the message are identified using the PartyId element and @type attribute. The following is an excerpt from an ebMS 3.0 message:

<eb3:PartyInfo>

   <eb3:From>

       <eb3:PartyId

          type="urn:oasis:names:tc:ebcore:partyid-type:0088"

          >4035811991021</eb3:PartyId>

       <eb3:Role>Buyer</eb3:Role>

   </eb3:From>

   <eb3:To>
         <!-- details omitted -->

   </eb3:To>

</eb3:PartyInfo>

3.3 Universal Business Language (UBL)

The Universal Business Language 2.0 OASIS Standard [UBL2] defines a number of XML document schemas to support electronic business.  These documents contain elements referring to parties in various roles. For example, an Order document has BuyerCustomerParty and  SellerSupplierParty elements. These elements contain a common Party group that has an optional PartyIdentification element. The ID element in this element has an optional @schemeID element that could use the proposed URN as a standard identification mechanism. The content of the ID element contains the identifier in the referenced identification scheme.  

<cac:BuyerCustomerParty>

  <cac:Party>

     <cac:PartyIdentification>

       <cbc:ID

         schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"                                  

       >4035811991021</cbc:ID>

     </cac:PartyIdentification>

  </cac:Party>

</cac:BuyerCustomerParty>

<cac:SellerSupplierParty>

  <cac:Party>

     <cac:PartyIdentification>

       <cbc:ID

         schemeID="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"                                  

       >4035811991014</cbc:ID>

     </cac:PartyIdentification>

  </cac:Party>

</cac:SellerSupplierParty>

3.4 UN/CEFACT XML Schemas and OAGIS

The @schemeID attribute also occurs in two other e-business libraries:

3.5 UN/CEFACT Standard Business Document Header (SBDH)

The Standard Business Document Header specification [SBDH] is a result of a work project of the UN/CEFACT Applied Technology Group (ATG). It provides a consistent interface between applications and provides the semantic information needed for the routing, processing and business domain context of documents, regardless of the data format of the document. The schema contains Sender and Receiver groups, containing an Identifier element with an @Authority attribute that serves a similar role to the @type attribute in ebXML CPPA and messaging, and to @schemeID in UBL.

<sh:StandardBusinessDocument

xmlns:sh=
    "http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">

<sh:StandardBusinessDocumentHeader>

<sh:HeaderVersion>2.2</sh:HeaderVersion>

<sh:Sender>

<sh:Identifier
           Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"                                                  

            >2203148000007</sh:Identifier>

</sh:Sender>

<sh:Receiver>

<sh:Identifier

            Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088"

            >6903148000007</sh:Identifier>

</sh:Receiver>

    <!-- Remainder of sample omitted -->  

 

 

4 Conformance

Conformance targets for this specification include:

and

For any of these artifacts to claim conformance to this specification, any element or attribute that:

  1. 1.provides typing information for party identification  

  2. 2.has a anyURI (or more general, e.g. string) type  

  3. 3.and has any of the following strings as a prefix of its value:  
    urn:oasis:names:tc:ebcore:partyid-type 

urn:oasis:names:tc:ebxml-cppa:partyid-type

MUST satisfy all the MUST and REQUIRED level requirements defined in this specification.

Furthermore, for any of these artifacts to claim conformance to this specification, any element or attribute that meets requirements (1) and (2):

  1. 4.MAY use the compatibility URN defined in section 2.6 in situations where backward compatibility is required. It SHOULD NOT be used in new applications. 

  2. 5.SHOULD set the party identification type value as specified in section 2.2 if the party ID type is registered in the ISO 6523 registry. 

  3. 6.MAY specify the party identification type as specified as in section 2.3 in the context of exchange of EDIFACT messages. 

  4. 7.SHOULD set the party identification type value as specified in section 2.4 if the party ID type is a registered ISO 20022 Data Source Scheme. 

  5. 8.SHOULD use the “unregistered” scheme of section 2.5 in all other situations. 

 

 

  1. Appendix A.Acknowledgments 

The editors would like to acknowledge the contributions of the completed OASIS ebXML Collaboration Protocol Profile and Agreement (CPPA) Technical Committee, which contributed its uncompleted documents to the OASIS ebXML Core (ebCore) Technical Committee.

The editors would also like to acknowledge the contributions of the OASIS ebXML Core (ebCore) Technical Committee, whose voting members at the time of publication were:

Participants: