OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] <PartyId =?UTF-8?Q?type=3D=22=3FSWIFT=20BIC=3F=22=3EBBBBC?==?UTF-8?Q?CLL=31=32=33=3C=5CPartyId=3E?=

My suggest is to use the OASIS wiki to support this in future - simple to maintain and find.

We will have to request tc-admin to set ebcore up - http://wiki.oasis-open.org/ 

Then we could "fix" the broken link by a redirect to the appropriate wiki page.

Thanks, DW

-------- Original Message --------
Subject: RE: [ebxml-dev] <PartyId type="?SWIFT
BIC?">BBBBCCLL123<\PartyId>
From: "Pim van der Eijk" <lists@sonnenglanz.net>
Date: Wed, August 05, 2009 3:11 pm
To: "'Moberg Dale'" <dmoberg@axway.com>,
<charles.kilkenny@actuare.com>, <ebxml-dev@lists.ebxml.org>
Cc: "'Pim van der Eijk'" <pvde@sonnenglanz.net>

Dale and others,
 
There was some discussion on this recently on UBL-DEV:
http://lists.oasis-open.org/archives/ubl-dev/200907/msg00012.html
 
For SWIFT, something like:
 
urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0021
 
would work. 
 
Pim


From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 05 August 2009 17:40
To: charles.kilkenny@actuare.com; ebxml-dev@lists.ebxml.org
Cc: Pim van der Eijk
Subject: RE: [ebxml-dev] <PartyId type="?SWIFT BIC?">BBBBCCLL123<\PartyId>

Hi,
 
 
Thanks for pointing out the broken link. I will ask OASIS whether they can fix it. The ebCore TC now is charged with maintenance of CPPA versions.
 
The version 3 of CPPA is progressing slowly and will have the approved party id identifier material included whenever we are able to finish the editorial work.
 
Meanwhile the material from version 3, section 4.3.1 (subject to change) that should also be at the link is attached to this reply. It is in the open office open document format. (There may be some variation from the material at the link but I cannot be certain until I get OASIS to fix the link.)
 
[Also the text is short enough to insert after discussion of the SWIFT value.]
 
 Now for Swift from ISO 6523 Data interchange- Structure for the identification of organizations, I find
 
ICD : 0021
Name of coding  system: SOCIETY FOR WORLDWIDE INTERBANK FINANCIAL
 TELECOMMUNICATION S.W.I.F.T.
Name & address : SOCIETY FOR WORLDWIDE INTERBANK FINANCIAL
of issuing TELECOMMUNICATION S.W.I.F.T.
organization Avenue Adele,1
B - 1310 La Hulpe
BELGIUM
Tel: +32 2 6553111
Fax: +32 2 6553226
Structure of : 1) ICD 4 Digits
code Organization code upto 11 characters
Organization name upto 250 characters
2) None
Display : None
requirements
Description of : Bank's identifiers for financial transfer on the
organizations S.W.I.F.T. Network.
covered by
coding system
Notes on use : To be used for assignment of object identifiers
of code (ISO 8824/8825)
Sponsoring : S.W.I.F.T.
authority
Date of issue : September 1990
of ICD
Additional : None
Comments
 
Unfortunately an explicit abbreviated name entry is not provided, although S.W.I.F.T is apparently intended.
 
This would mean that the method (approved by the old CPPA TC) currently  yields within the approved errata for version 2, either
 
urn:oasis:names:tc:ebxml-cppa:partyid-type:S.W.I.F.T:0021
 
or
 
urn:oasis:names:tc:ebxml-cppa:partyid-type:SocietyForWorldwideInterbankFinancialTelecommunicationS.W.I.F.T.:0021
 
I like the shorter one. Both of these are the party-id type values. Explicit values for banks would presumably be defined by SWIFT and these would be the actual party id values, as your subject line shows.
                                                              
Also, I should mention that, for version 3,   I must check whether the above two options are the only options -- with Pim van der Eijk, as it seems to me that an additional shortening of uuid has been under discussion for version 3. It apparently has not made its way into the current working draft for version 3.
 
 

PartyId Element

The PartyID element provides an identifier that SHALL be used to logically identify the Party. The value of the PartyID element is an non-empty string that provides an identifier. This is the convention used, for example, within a CPP or CPA when leveraged with ebMS.

The PartyId element has a single attribute: type that has an anyURI [XMLSCHEMA-2] value. In a CPP or CPA, the type value of the type attribute SHOULD be a URN [RFC2141] that defines a namespace for the value or content of the PartyId element. Typically, the URN would be registered in a well-known directory of organization identifiers.

For a CPP or CPA, if the type attribute is not present, the value or content of the PartyId element MUST be a URI that conforms to [RFC2396].

While an identifier may be understood by both Parties in a CPA, messaging protocols such as ebMS recommend the use of URIs. Within ebMS, the value or content of the PartyId MUST be a URI that conforms to [RFC2396].

Additional PartyId elements MAY be present under the same PartyInfo element so as to provide for alternative logical identifiers for the Party. In a CPP, if the Party has preferences as to which logical identifier is used, the PartyId elements SHOULD be listed in order of preference starting with the most-preferred identifier.

In a CPP that contains multiple PartyInfo elements, different PartyInfo elements MAY contain PartyId elements that define different logical identifiers. This permits a large organization, for example, to have different identifiers for different business or other technical purposes.

If multiple PartyId elements occur under the same PartyInfo element in the CPA, all of those PartyInfo elements MUST be included in the Message Header. This applies, for example, when protocol bindings such as ebMS v2 are used.

The value of the PartyId element is any string that provides a unique identifier. The identifier MAY be understood by both Parties to a CPA. Several schemes exist for naming identifier domains. [ISO6523] enumerates values for many domains: the domain is identified by a four-digit numeric sequence. For example, the ISO 6523 ICD 0060 identifies the Dun & Bradstreet domain. Typically, the identifier would be listed in well-known directories such as DUNS (Dun and Bradstreet) or in any naming system specified by [ISO6523].

Alternatively, the code list for ISO 9735 (UN/EDIFACT syntax) D.3 Service simple data element 0007 (routing Identification Code qualifier) can be used to name identifier domains [ISO9735]. ANSI ASC [X12] Data Element I05 (Interchange ID Qualifier) element, used in the ISA Interchange Control Header segment, also provides a list of code values for naming domains.

These three serve as "catalogues" of schemes for naming identifier domains; processes exist by which additional domains can be identified through the Registration Authorities (RA):

  • the British Standards Institute (BSI): ISO 6523
  • ISO/TC154-UN/CEFACT Joint Syntax Working Group (JSWG): [ISO9735] D.E Service simple data element 0007
  • ANSI ASC X12: X12 Data Element I05

The following example shows how URNs are used for the type attribute and for the PartyId element value.

<PartyInfo partyName="CompanyA" defaultMshChannelId="asyncChannelA1"

defaultMshPackageId="CompanyA_MshSignalPackage">

<PartyId type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">123456789</PartyId>...

 

<tp:PartyId>urn:icann:example.com</tp:PartyId>

The first example indicates the Party's DUNS number for the organization using a type attribute with a URN value. The value of the PartyId element itself is the DUNS number of the organization, which is a string of digits assigned by the agency. The second example shows an arbitrary URN as a PartyId value. No type is indicated, but the value might be a URN that the Party has registered with the Internet Assigned Numbers Authority [IANA] (http://www.iana.org) to identify itself directly.

When these naming conventions are used, values are generated for the type attribute from information items using a well-known directory of organization identifiers such as ISO6523. A method to standardize URNs used as PartyId@type values using ISO6523 is described. This method adheres to the rules, requirements and recommendations of a CPP or CPA, or ebMS.

An implementation SHOULD provide support, and be able to accommodate, the usage of the type values standardized herein (See four bullets that follow).

  • 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:ebxml-cppa:partyid-type:” to the abbreviated name and appending a colon “:” followed by the ICD value. For example, using the abbreviated name D-U-N-S Number:

Abbreviated Name: “D-U-N-S Number”

Upper-camel-case resultant string: “D-U-N-SNumber”

tp:type=" urn:oasis:names:tc:ebxml-cppa:partyid-type:D-U-N-SNumber:0060"

 

Note: “0060” is the ICD value of D-U-N-S Number.

To be consistent with v2 CPP/A, the value that follows remains a valid type attribute value or content for the PartyId element: “urn:oasis:names:tc:ebxml-cppa:partyid-type:duns”.

  • 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:ebxml-cppa: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”

tp:type=" urn:oasis:names:tc:ebxml-cppa: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.

 

 
 
 
From: charles.kilkenny@actuare.com [mailto:charles.kilkenny@actuare.com]
Sent: Wednesday, August 05, 2009 7:38 AM
To: ebxml-dev@lists.ebxml.org; charles.kilkenny@actuare.com
Subject: [ebxml-dev] <PartyId type="?SWIFT BIC?">BBBBCCLL123<\PartyId>
 
Hi,
The link at http://www.oasis-open.org/committees/ebxml-cppa/documents/PartyID_Types.shtml referenced in the ebcpp-2[1].1-april-5-2005-draft.doc document appears to be broken.
I've searched and searched, and sorry if these questions have already been asked ... does anybody know where the list of ebMS PartyId type URNs are maintained? Does anybody know the URN for a SWIFT BIC (ISO-9362)? I would guess "urn:swift" would be insufficient and it is not clear whether the URN is ISO or SWIFT. Also, ISO 6523 only gives the code "0021" and not the URN. RFC 3615 doesn't help either.
Thanks.
Charles
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]