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

["Moberg Dale" <dmoberg@axway.com>]

>     skype:adrian.m.mueller

>.My 2 cents concerning the topics raised:

>>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, 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.

So, I think you are saying that there would be a need to clear URIs
starting with "urn:iso..." with that organization for the party id class
identifiers. That was my guess, and your research seems to be consistent
with that hypothesis. 

>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.
> 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).

Good observations. Thanks for pointing this out.

[ snips]
>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.)

It would be good if the identifiers for senders, data creators, service
consumers, event publishers, and their counterparts were less of a mess
than they are. We haven't even mentioned their use in the Distinguished
Names of X.509 or the varieties or username, password, and related
credentials in use.
My experience so far has been that it is very hard to arrive at decent
solutions on identifiers for organizations that get international
consensus.
And the sources of controversy are many and varied. Communication
protocols are pretty much forced to leave pluggable points for these
values that are hoped to be open enough to accommodate current and
future conventions. Even specifying the use of a URI, rather than a
string, has had its pitfalls, as you note.


>Best regards>	Adrian

Thanks again for your remarks.