RE: [ebcore] PartyId Type remark

Dear 
all,

 

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 

 

 

From: Moberg Dale [mailto:] 

Sent: 23 March 2010 16:26
To: David RR Webber (XML); Sander 
Fieten
Cc: 
Subject: RE: [ebcore] 
PartyId Type remark

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:] 
Sent: Tuesday, March 23, 2010 8:09 
AM
To: Sander 
Fieten
Cc: 

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 <>
Date: Mon, March 22, 2010 4:46 
  pm
To: "" 
  <>

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
    
  

--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that generates 
this mail. Follow this link to all your TCs in OASIS at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php