Michael Ströder wrote:

Pierangelo Masarati wrote:

...

I've developed a module that implements support for the syntax of "codice fiscale", the personal identification code used by the Italian government to uniquely identify citizen.

Well, we currently get such a number in Germany too.

...

I think it might be of general use, although possibly limited to Italian users, so I'd like to give it a somewhat official and unbiased OID, rather than one under my arc or SysNet's. Would it qualify as general enough for OpenLDAP's OID arc, at least while experimental?

Well, when assigning OIDs there are two options:

1. the pragmatic approach: Use any OID arc you want since no-one ever

cares. This seems to be the most common approach and works within a reasonable time-frame. Even OID arcs (enterprise IDs) looking very "official" seem to be assigned with this approach.

2. the "official" approach: Try to convince an official numbering

authority to do the job. In your case that would the relevant Italian government agency or the central Italian bank. Be prepared for either being totally ignored or involved into really bizarre discussions. Also be prepared to wait at least two years for it. (Do you know the movie "Brazil"?)

I don't see why an OpenLDAP OID should look somewhat "more official" than any other OID arc. Just my two EUR cent. ;-)

Let's say more "neutral". I'm considering using a temporary OID from the experimental arc. For the rest, who knows?

...

I believe the need for a dedicated syntax (as opposed to IA5string, printableString or so) is that its definition, although flawed, needs to conform to quite a few restrictions, and a syntax that allows to detect trivial errors and single out impossible values would be definitely helpful.

Is there kind of a checksum digit?

Yes, but the whole design is flawed (in fact, the government seems to be considering the opportunity of changing it to something more reliable; I expect significant bureaucratic simplifications from this ;)

...

An OID arc would be best, because the kit consists in:

• a syntax
• an equality matching rule (cfMatch)
• an attribute spec (cf)
• an auxiliary objectClass spec (cfObject)

Why do you need a matching rule?

Well, you're probably right: given the syntax specification, after validation a simple octet string match suffices.

Is there a required normalization step like stripping white spaces before comparing it? (Frankly I'm not eager diving into the specification of this number though.)

Nobody would :)

I could imagine a more general matching rule useful which strips spaces and then conducts numericStringMatch, caseIgnoreIA5Match etc.

Also I'd prefer a naming prefix slightly more verbose than 'cf' and reflecting the use for Italy. Maybe something like 'itcodefisc' or similar?

Thanks for the suggestions. I'll take them into account.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------

Kurt Zeilenga wrote:

On Oct 28, 2008, at 10:50 AM, Pierangelo Masarati wrote:

...

I've developed a module that implements support for the syntax of "codice fiscale", the personal identification code used by the Italian government to uniquely identify citizen. I think it might be of general use, although possibly limited to Italian users, so I'd like to give it a somewhat official and unbiased OID, rather than one under my arc or SysNet's.

I'm not sure what you mean by "official and unbiased OIDs".

I meant something like "neutral", and strictly for a "work in progress" phase, until I find whether there's any official agency willing to support this initiative somehow (I'm not optimistic, as you can infer).

OIDs are either properly delegated or not. Two properly OIDs are equally official and have no bias. They are just a sequence of numbers after all.

Now different delegators have different biases, but these biases have no impact on the technical aspects of the protocols.

...

Would it qualify as general enough for OpenLDAP's OID arc, at least while experimental?

To qualify, the question is not whether the use is "general enough".

Exactly.

Simply put, the OpenLDAP OID arc is for the Project's use. It's not for the use by other enterprises.

It primarily used for early implementations of LDAP extensions in OpenLDAP Software, such as when the standards development organization producing the extension specification has not yet assigned OIDs for extension elements. It's also used for extensions specific to OpenLDAP Software and/or the OpenLDAP Project.

Generally speaking, OpenLDAP OID should only be used to identify elements used in OpenLDAP Software and otherwise don't otherwise have an OID.

This use is not for my enterprise, otherwise I would have had no doubt, and used SysNet's arc. It's a voluntary contribution to OpenLDAP, in order to provide support for this feature and hopefully encourage other implementors (and users) towards supporting (and using) this instead of hijacking employeeNumber, description, myCodiceFiscale and so on. So I infer the answer is: yes, an OID from OpenLDAP's experimental OID arc would be appropriate for the "work in progress" phase (beware that it could last forever :).

...

I believe the need for a dedicated syntax (as opposed to IA5string, printableString or so) is that its definition, although flawed, needs to conform to quite a few restrictions, and a syntax that allows to detect trivial errors and single out impossible values would be definitely helpful. I need the OID in order to submit code along with an ITS for contrib. An OID arc would be best, because the kit consists in:

• a syntax
• an equality matching rule (cfMatch)
• an attribute spec (cf)
• an auxiliary objectClass spec (cfObject)

Speaking generally (for all contributions):

If you use a dummy OID (e.g., 1.1) in your contribution (and document this), then the project should, if your contribution is accepted, assign an appropriate OID upon integration.

If you want to make use of your contribution before integration, I would suggest you assign an OID from your arc and submit using that.

Speaking with regard to this particular situation, my primary concern would be whether your or our assignment would conflict with that of the organization standardizing "codice fiscale". This might be a case where we want to consider our code an "early implementation" of a yet published standard (where use of a .666 OID is appropriate). I'm not familiar enough with "codice fiscale" to know whether its developers would ever assign an OID.

Codice Fiscale is based on a law of 1976; the fact there is no standard attribute for it, nor any vendor to my knowledge provides an attribute for it seems indicative of the importance it has in the (Italian) LDAP users community. The typical approach seems to consist in hijacking another attribute generic enough to hold it, with detrimental consequences on interoperability.

If it wasn't for that, I would say: just submit the contribution to see if there were any objections to its integration and, if none, integrate it using either your OID (if you already assigned one) or an OpenLDAP OID (if not).

I'll follow this route. Thanks, p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------