RE: [ebxml-dev] <PartyId =?UTF-8?Q?type=3D=22=3FSWIFT=20BIC=3F=22=3EBBBB

-------- Original Message --------
Subject: RE: [ebxml-dev] <PartyId type="?SWIFT
BIC?">BBBBCCLL123<\PartyId>
From: "Charles Kilkenny" <charles.kilkenny@actuare.com>
Date: Thu, August 06, 2009 12:24 pm
To: "'Moberg Dale'" <dmoberg@axway.com>, "'David RR Webber (XML)'"
<david@drrw.info>, "'Pim van der Eijk'" <lists@sonnenglanz.net>
Cc: <ebxml-dev@lists.ebxml.org>, <ebcore@lists.oasis-open.org>

Hi Dale/Pim & David,

Many thanks for your responses. They have been really helpful.

I can’t help saying though that the following could give the computer repetitive strains:

1. urn:oasis:names:tc:ebxml-cppa:partyid-type:S.W.I.F.T:0021

2. urn:oasis:names:tc:ebxml-cppa:partyid-type:SocietyForWorldwideInterbankFinancialTelecommunicationS.W.I.F.T.:0021

This is a lot better:

3. urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0021

And, this would be even better:

4. urn:iso6523:0060

Option (4) would also remove “ebxml” (sorry all you ebXML folks) which would enable it to be used outside of ebXML and hence have even more global adoption J

There may just be one snag however and I’m not completely sure. I’m not sure whether SWIFT is just the registrar (I suspect though that this is the case) or whether it actually owns the BIC coding scheme. If the former, the following may be more appropriate:

5. urn:iso9362:1994

An authoritative Wiki as a central repository would also be great. I could then stop searching!

Thanks again.

Charles

From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 06 August 2009 17:51
To: David RR Webber (XML); Pim van der Eijk
Cc: Pim van der Eijk; charles.kilkenny@actuare.com; ebxml-dev@lists.ebxml.org; ebcore@lists.oasis-open.org
Subject: RE: [ebxml-dev] <PartyId type="?SWIFT BIC?">BBBBCCLL123<\PartyId>

Let’s discuss tomorrow morning on ebCore call. Dale Moberg

(I think the iso6523 allows short identifiers for all iso registered values. Not certain that iso is maintaining that code list however.)

Good idea to have a wiki. We could post all the known v2 and v 3 codes deriving from code registries.

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Thursday, August 06, 2009 7:46 AM
To: Pim van der Eijk
Cc: 'Pim van der Eijk'; Moberg Dale; charles.kilkenny@actuare.com; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] <PartyId type="?SWIFT BIC?">BBBBCCLL123<\PartyId>

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

ebcore message