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"?
<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>
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
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]
Sent: 10 August 2009 12:30
To: charles.kilkenny@actuare.com; ebxml-dev@lists.ebxml.org;
ebcore@lists.oasis-open.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
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