FYI.
From: Pim van der Eijk
[mailto:]
Sent: 07 August 2009
09:20
To: ''; 'Moberg Dale'; 'David RR
Webber (XML)'
Cc: '';
''
Subject: RE: [ebxml-dev] <PartyId
type="?SWIFT BIC?">BBBBCCLL123<\PartyId>
Hello,
IANA assigns the URN top-level namespaces, and OASIS applied for the "urn:oasis" one and (at
one point) defined "names:tc" branch so TCs could define their own special-purpose
namespaces. The OASIS TC has
defined a sub-branch to refer to ISO 6523 registered organizations. Those
organizations would need to apply to the registration holder for ISO 6523
themselves separately (I believe 6523 is handled by the BSI). It would
probably be a good idea for the OASIS TC to also define a urn:oasis:names:tc:ebxml-cppa:partyid-type:iso15022
branch for organizations classified according to ISO
15022.
The CEN workshop people that proposed the "iso6523"
branch will need to register it with IANA themselves, and their CWA indicates
this is their intention. If you want to use something like urn:iso9362:1994 or urn:iso15022 then in theory someone should apply for such top
level URN domains.
However there is
no mechanism to resolve URNs like there is for HTTP URLs, so in reality these
URNs are just identifier strings.
There is indeed a
lot of overlap in these registrations. Companies are classified on
multiple schemes, and those classification schemes are in turn classified based
on multiple meta-registration schemes like 6523 and 15022. And now we are
discussing multiple ways of designating such meta-registration schemes.
There is more than one way that leads to Rome
..
Pim
From: Charles Kilkenny
[mailto:]
Sent: 06 August 2009
18:50
To: 'Moberg Dale'; 'David RR Webber (XML)'; 'Pim van der
Eijk'
Cc: ;
Subject: RE: [ebxml-dev] <PartyId
type="?SWIFT BIC?">BBBBCCLL123<\PartyId>
Hi,
Also, looking at it
from a banking and finance perspective … what to do about other identifiers
issued by exchanges (http://www.iso15022.org/MIC/homepageMIC.htm)
or by central securities depositories (http://www.iso15022.org/Data_Source_Schemes.pdf)?
Currently, these party identifiers are represented by a 4 character scheme e.g.
“CRST” = “Euroclear CREST” followed by the participant code. That is in ISO
15022 speak. And, some issuers, e.g. messaging network operators, are not even
represented as a DSS (ISO 15022 data source scheme). Also, I guess ISO 15022 DSS
most probably overlaps other schemes.
Charles
From: Charles
Kilkenny [mailto:]
Sent: 06 August 2009 18:24
To: 'Moberg Dale'; 'David RR Webber (XML)';
'Pim van der Eijk'
Cc:
''; ''
Subject: RE: [ebxml-dev] <PartyId
type="?SWIFT
BIC?">BBBBCCLL123<\PartyId>
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:]
Sent: 06 August 2009 17:51
To: David RR Webber (XML); Pim van der
Eijk
Cc: Pim van der Eijk;
;
;
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:]
Sent: Thursday, August 06, 2009 7:46
AM
To: Pim van der
Eijk
Cc: 'Pim van der Eijk';
; ;
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" <>
Date: Wed, August 05, 2009 3:11
pm
To: "''"
<>,
<>,
<>
Cc: "'Pim van der Eijk'"
<>
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: [mailto:]
Sent: 05 August 2009
17:40
To: ;
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
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: [mailto:]
Sent: Wednesday,
August 05, 2009 7:38 AM
To:
;
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
