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 type="?SWIFT BIC?">BBBBCCLL123<\PartyId>

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? 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"?


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!!





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>

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.


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 the tradeoffs ensure that every protocol can have its proponents and detractors.



Best regards,

On Tue 11/08/09 5:27 AM , "Charles Kilkenny" charles.kilkenny@actuare.com sent:

-----Original Message-----
From: Adrian Mueller [adrian@mueller-consulting.biz]
Sent: 10 August 2009 12:30
To: charles.kilkenny@actuare.com; ebxml-dev@lists.ebxml.org;
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

Best regards


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- =

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

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

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

phone +41 44 500 50 94
mobile +41 79 502 53 45


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