RE: [ebcore] PartyId Type remark

In practice, URNs are just identifiers, so if it is just to have a URI syntax partyid type identifier, everybody can just make up their urn:whatever identifiers. Examples are abundant that show that people (and companies, groups writing specs etc.) are doing that precisely and often don't care about registering with IANA at all. Instead however, the purpose of the original request to CPA TC, and by extension of this specification, was to provide a formal URN for this identifier from an IANA registed NID. This fact indicates a preference for a scheme that has gone through some minimal form of validation. IANA has done that, by registering OASIS through RFC 3121. That in turn places some responsibility on OASIS, which recognizes its TCs, such as ebCore. And on ebCore, which further subclassifies the identifier.

ISO 6523 which the original proposal was about is the international standard party id catalogue, not just one of an arbitrary number of catalogues. CWA 16036 is a recent 89 page deliverable of a one year CEN project on just party identification, and their research does not suggest that there are many of them, or a need to support an arbitrary number of them: in fact it recommends using ISO 6523 and even references the earlier CPA work. The schemes in the 6523 catalogue cover tens (if not hundreds) of millions of companies globally. The single limit that ISO 6523 syntax has is that it is not URI-compliant. There is nothing that makes it a legacy format. Perhaps we should have left it at that and endorsed ISO 6523 as per the original proposal. I know I've created a precedent by adding some other options (more on them below). Opening up the prefix to arbitrary party id type catalogues is the other extreme. The effect would just be to construct a URN in a registered NID that is as meaningless and unvalidated as any self-invented URN. By using the same syntax as for an established catalogue like ISO 6523, it devalues those schemes and the proposal itself. The purpose of the specification is to support implementations that want to limit the value of party id type to an established set of formally recognized schemes based on international schemes. Generalizing it to arbitrary scheme catalogues is a distraction.

Again, I almost regret adding the other two catalog types. (1) The EDIFACT one is mainly intended to support easy bridges from classic EDI VANs to ebXML or other more modern networks. I know there is interest in this, so added it. We could have used this one as the only catalogue instead as its value '30' in fact identifies a branch for 6523. Or omitted it, as I think all or most of its other values (I did not check all of them) are also in 6523. (2) The 20022 DSS does seem to contain a range of systems not in 6523, and there were requests on ebXML-Dev referring to party identification in financial services that I wanted to respond to.

None of there three are 100% limitative in the spec, as there already is an explicit escape in 2.5, which would allow a scheme bar in different catalogue foo to be expressed as urn:oasis:names:tc:ebcore:partyid-type:unregistered:foo:bar This value, different from allowing arbitrary catalogues at the same levels as the established schemes, explicitly signals the difference with these established international standard classifications yet offers the same extensibility. It is similar to the 'ZZZ' value in EDIFACT 0007 ('mutually defined' ).

If we as TC find important new scheme catalogues other than the ones in the current spec in the future, we could always update this document to include them. My sense is that that would be unlikely as we have covered the main catalogues with these three options.

Governments that have their own code system catalogues could always register them with BSI to have them included in ISO 6523. Even better government agencies could use established schemes like GLN instead of inventing new schemes for themselves (or even imposing new ones on businesses), as some smart countries (not the one I am a resident of) are doing.

Pim

The previously agreed upon formats for party-id-type identifiers need to be retained because of votes made in ebCPPA TC. Most of the previous procedures for constructing identifier values were formulated by ECOM, and certain fine points arising from URI character set restrictions were added.

Possibly the first paragraph needs to emphasize some background context:

0. Legacy identifiers are not URIs so TC asked to suggest a way to produce URI reflecting legacy naming identifier schemes (registered with ISO…)

1. Preservation of old procedures and identifiers is accepted good practice.

2. New procedure and new “naming (sub) authority”. using the “ebcore” substring as mentioned below.

3. Reminder that these identifiers are supplied as guidance in using existing naming authorities registered with ISO, and the procedures are not in any way meant to prevent community or even bilateral agreements on other URI values for party-id-type codes (this is clearly how ebMS left it).

Should anything be said about using non-ISO codes for naming authorities? Will there be yet another set of codes for naming authorities for systems of identifying organizations? I would say that we just wait and see on that. Meanwhile, people are still free to invent URIs in their own URI naming authority space if they wish.

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, March 23, 2010 8:09 AM
To: Sander Fieten
Cc: ebcore@lists.oasis-open.org
Subject: RE: [ebcore] PartyId Type remark

Sander,

I agree.

No need to restrict this too much for users - instead need to offer clear guidelines on schemes to use to derive consistent URNs.

Thanks, DW

-------- Original Message --------
Subject: [ebcore] PartyId Type remark
From: Sander Fieten <sander@fieten-it.com>
Date: Mon, March 22, 2010 4:46 pm
To: "ebcore@lists.oasis-open.org" <ebcore@lists.oasis-open.org>

All,

The remark I tried to explain on last Friday’s call is about the general structure of the URN that’s being specified. As I already mentioned in my earlier e-mail about the first draft the general scheme looks like urn:oasis:tc:ebcore:partyid-type:[<catalog-identifier>:]<scheme-id within catalog>. The section on forming URN’s based on the ISO6523 scheme are not [all] consistent with this scheme.

Furthermore I think this general scheme can be used generally and not restricted to the three schemes currently defined in the draft. This would allow greater flexibility. For example this allows easy extension to government regulated schemes, like personal or businesses identification numbers. If we don’t want to create an “open ended” scheme, I think it can be usefull to add a category for such government regulated naming schemes.

Regards,
Sander

ebcore message