Re: [ebxml-dev] <PartyId type="?SWIFT BIC?">BBBBCCLL123<\PartyId>

[Adrian Mueller <adrian@mueller-consulting.biz>]

Der all,

My 2 cents concerning the topics raised:

Moberg Dale wrote:
> My responses only to some questions. ebCore TC would decide by consensus 
> what response would be made.
> 
>  
> 
> Adrian, my earlier email wasn't completely correct. It should have 
> stated: "And, this would be even better: 4. **urn:iso6523:0021**" 
> (rather than "0060"). Also, I believe it might as well have stated "And, 
> this may be even better: 6. **urn:iso9362 **" (without the ":1994" 
> suffix"). I believe SWIFT is just the registrar for BIC/BEI so surely 
> 9362 is more appropriate than 6523:0021? 

I am not BIC-expert, but I believe that both approaches would work and
that the SWIFT-ID ("urn:iso6523:0021") is in practice the same as the 
BIC ("urn:iso9362").

> Also, thank you for the link to 
> your CWA document which I hope to find some more time to digest and 
> sorry to have missed the deadline for public comment.
> 
> So, I would like to ask would ebXML use something like "urn:iso9362" or 
> "urn:iso6523:0021" if it existed, or would one continue to use an ebXML 
> prefixed string like 
> "urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0021"?
> 
> <DaleMoberg>
> 
> ebXML CPPA, consulting with the Asian Ecommerce organization Ecom and 
> its representatives, arrived at some standard identifiers that could be 
> used as Party ID Type identifiers. The use of these identifiers is not 
> required by the CPPA specification. Instead it is pretty much left to 
> specific communities to settle on what identification system is used, or 
> even whether one is used. (It is possible to omit PartyID types if you 
> use URIs for party ids!)
> 
> So within ebXML we tried to create some identifiers “available for use” 
> in CPPAs and in ebMS messages. We are planning to put these on a wiki 
> page along with any other identifers that organizations would like to 
> publicize for usage at Type identifiers. (We will not be a registry for 
> party id values, of course.) The reason for the long URIs is simple—that 
> is the only urn naming authority that we had in our TC to use in making 
> identifers! If we created urns like “urn:iso” it would be without any 
> registration with IETF for the use of those URNs, and it would impinge 
> on ISO authority to construct such identifiers if they decided to.
> 
> If ISO or any other organization wants to create URIs as identifying 
> values of Party ID Types (code authorities, naming registries, etc.) 
> that is perfectly allowed by ebXML. If they are short, so much the better!!
> 
>  
> 
> </DaleMoberg>
> 
>  
> 
>  
> 
> Also, looking at http://www.iana.org/assignments/urn-namespaces/ a URN 
> NID for "iso" already exists (RFC 5141). This would indicate having to 
> use something like "urn:iso:std:iso:9362" or 
> "urn:iso:std:iso:6523:blahh:0060". So, wouldn't the request for a 6523 
> namespace or for a single 9362 namespace be to ISO rather than to IANA?
> 
> <DaleMoberg> Given that ISO has done the naming authority registration 
> with IETF you would need to talk to ISO to form subpaths 
> (urn:iso:blah:blah) That is my understanding anyway. </DaleMoberg>
> 

It is my understanding of the "iso" URN NID according to RFC 5141 that
it is intended to uniquely identify ISO "resources", i.e. (standard)
documents and related data.
The urns "urn:iso:std:iso:9362" and "urn:iso:std:iso:6523" do therefore
identify the according standards / standard documents and *not* the 
identifiers registered according to these standards. So the usage of the 
"iso" NID for business identifiers (registered according to an 
ISO-standard) was not foreseen and would mean to extend the purpose of 
the "iso" NID.



A registered formal URN namespace which allows the usage of short
identifiers is the "oid" NID as described by RFC 3061. It is the
namespace for object identifiers (OID's). International Code
Designator Values (ICD's) according to ISO 6523 can also be used as part
of the object identifier hierarchical tree. Therefore, the following 
example does work:

<PartyID type="urn:oid:1.3.21">BBBBCCLL123</PartyID>

where 1.3.21 means
1 : ISO arc of the OID tree
3 : identified organisation (as registered according to ISO 6523)
21 : S.W.I.F.T.

(see also http://www.oid-info.com/get/1.3.21)


However, RFC 3061 specifies that under the "oid" NID only numeric OID's
(i.e. digits and '.') can be included. So the creation of an URN as
single string would not be allowed, i.e.

<PartyID>urn:oid:1.3.21:BBBBCCLL123</PartyID>

would violate the specification of RFC 3061 and therefore *NOT* be allowed.

So the "oid" NID could be used within the ebXML context, but not in 
contexts where you need a single string and have alphanumeric 
identifiers, e.g. for AS2 sender and recipient identification (see below).

> Also, wouldn't it make sense to have shortcut aliases within e.g. the 
> ebMS <PartyId type> attribute? e.g. "bic" = 
> "urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0021", and "duns" = 
> "urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0060". I really 
> can't see ebMS as being very useful in financial messaging if we have to 
> keep specifying 
> "urn:oasis:names:tc:ebxml-cppa:partyid-type:iso6523:0021" for the sender 
> and the receiver in every message!Dal
> 
> <DaleMoberg> I hope my previous remarks clarify that the values ebXML 
> CPPA TC created, done so by request of Ecom representatives, are allowed 
> values. The point is that users of ebXML MS can use whatever values they 
> want for party id types and can even dispense with the typing by using 
> URI values for party ids! So your concern about the unwieldy identifiers 
> is misplaced because they are not required for using ebMS.</DaleMoberg>
> 
> Likewise, participation in a messaging network or with e.g. a CSD 
> shouldn't involve lengthy strings for the sender/receiver in every 
> message. i.e. if that is your main messaging domain. Something like 
> "urn:com:euroclear:sicovam" or just "sicovam" may be a lot more useful 
> than something like 
> "urn:oasis:names:tc:ebxml-cppa:partyid-type:iso15022:sicv". Also, it 
> would be nice to minimise the impact of the ownership of these market 
> infrastructures changing.
> 
> <DaleMoberg>
> 
> Well, there is some diagnostic value in repeating message or payload 
> metadata within messages. But, more important, if CPPA were used, 
> perhaps nearly all metadata could be offloaded out of the message just 
> by citing the CPAid (or in version 3 ebMS, the AgreementRef) But because 
> the parts of ebXML were to be useable both together and independently, 
> ebMS could not presume that CPPA was in use. So ebMS created a header, 
> repeating a lot of the metadata on the message that is statically stored 
> in the CPA. Tradeoffs. It is hard to find a balance between stored state 
> (metadata contracts) and dynamic messages (favoring stand-alone, 
> self-contained message metadata ) that pleases every sensibility. WS 
> specs tend to move strongly away from any stored state and so tend to be 
> even chattier than ebMS and much more so than in REST-like approaches 
> such as that found in AS2, which is minimalistic on metadata!) Anyway 

Since you mention AS2:

For AS2 you (D. Moberg) specified the "AS2-To" and "AS2-From" headers 
for sender and recipient identification. Wouldn't it be nice to use the 
same kind of URN in these headers as we have discussed them above?

(Of course, you wouldn't use BIC's there as URN's but GLN's, DUNS or 
official registry numbers, etc.)


Best regards

	Adrian


> the tradeoffs ensure that every protocol can have its proponents and 
> detractors.
> 
> </DaleMoberg>
> 
>  
> 
> Best regards,
> Charles
> 
> *On Tue 11/08/09 5:27 AM , "Charles Kilkenny" 
> charles.kilkenny@actuare.com sent:*
> 
>     -----Original Message-----
>     From: Adrian Mueller [adrian@mueller-consulting.biz
>     <javascript:top.opencompose(>]
>     Sent: 10 August 2009 12:30
>     To: charles.kilkenny@actuare.com <javascript:top.opencompose(>;
>     ebxml-dev@lists.ebxml.org <javascript:top.opencompose(>;
>     ebcore@lists.oasis-open.org <javascript:top.opencompose(>
>     Subject: Re: [ebxml-dev] BBBBCCLL123<\PartyId>
> 
> 
>     Charles Kilkenny wrote:
>     ...
>     >
>     >
>     >  And, this would be even better:
>     >
>     >
>     >
>     >  4. urn:iso6523:0060
>     >
>     >
>     >
>     ...
> 
>     Dear Charles Kilkenny,
>     Dear all,
> 
>     This statement is reassuring to see. As mentioned by Pim van der Eijk
>     before, we have come to the same conclusion in the CEN Workshop on
>     Cyber-Identity (Unique identification systems for organisations and
>     parts thereof). The URN namespace identifier "iso6523" should be
>     registered.
>     (http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/ws_c
>     yberid.asp)
> 
> 
>     Best regards
> 
>     Adrian
> 
> 
>     -- 
>     Adrian MUELLER
>     Dr. Otto Mueller Consulting
> 
> 
>     Dr. Otto Mueller Consulting is registered in trustworthy directories.
>     These registrations show the existence of Dr. Otto Mueller Consulting
>     and provide relevant information about this company.
>     Use the service UNIVERSE® of the Ticino Chamber of Commerce and
>     Industry
>     to verify these registrations(Commercial Registry of Zurich and D&B
>     D-U-N-S® Nr):
> 
>     <http://universe.cciati.ch/urn/?urn=urn:iso6523:0169:CH-020.1.021.491-5&urn
>     =
>     urn:iso6523:0060:481453301>
> 
> 
>     Office address:
>     Dr. Otto Mueller Consulting
>     c/o ID Cyber-Identity Ltd
>     Technoparkstr. 1
>     8005 Zürich
>     SWITZERLAND
> 
>     Map: <http://map.search.ch/zuerich/technoparkstr.1>
> 
> 
>     Legal address:
>     Dr. Otto Mueller Consulting
>     Alte Landstr. 19
>     8803 Rueschlikon
>     SWITZERLAND
> 
> 
>     http://www.mueller-consulting.biz
>     skype:adrian.m.mueller
>     phone +41 44 500 50 94
>     mobile +41 79 502 53 45
> 
>  
> 

-- 
Adrian MUELLER
Dr. Otto Mueller Consulting


Dr. Otto Mueller Consulting is registered in trustworthy directories.
These registrations show the existence of Dr. Otto Mueller Consulting
and provide relevant information about this company.
Use the service UNIVERSE® of the Ticino Chamber of Commerce and Industry
to verify these registrations(Commercial Registry of Zurich and D&B
D-U-N-S® Nr):

<http://universe.cciati.ch/urn/?urn=urn:iso6523:0169:CH-020.1.021.491-5&urn=urn:iso6523:0060:481453301>


Office address:
Dr. Otto Mueller Consulting
c/o ID Cyber-Identity Ltd
Technoparkstr. 1
8005 Zürich
SWITZERLAND

Map:	<http://map.search.ch/zuerich/technoparkstr.1>


Legal address:
Dr. Otto Mueller Consulting
Alte Landstr. 19
8803 Rueschlikon
SWITZERLAND


http://www.mueller-consulting.biz
skype:adrian.m.mueller
phone  +41 44 500 50 94
mobile +41 79 502 53 45