[x500standard] SV: Re: SV: Re: SV: Re: SV: Re: New defect report on missing organisation information
- From: "Erik Andersen" <era@xxxxxxx>
- To: "Directory list" <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 2 Apr 2012 12:31:59 +0200
Hi Steve,
Thanks for your comments. Identifying such gaps in the X.500 schema
definition would require some input from vendors and administrators. It
would not be proper if we just go ahead ourselves and invent new schema
elements at random.
The proposed new attribute type was the result of a particular request and
not by my own ingenious invention. As I felt the attribute type was of
general use, I suggested the addition to X.520.
Back in the old days of workshops (EWOS and ISSS) we defined some schema
elements using an ISSS OID branch. These definition is provided on our
Website (http://www.x500standard.com/index.php?n=X500.ISSSSchema). They are
somewhat outdated and should be removed. However, some of schema element,
possibly in a modified form, could be part of the X.520 using X.500 OIDs.
We still have the problem pointed out by David that we do not have a good
procedure for adding new common usable schema element as they are
identified.
Regards, Erik
-----Oprindelig meddelelse-----
Fra: Steve Kille [mailto:steve.kille@xxxxxxxxx]
Sendt: 2. april 2012 11:36
Til: x500standard@xxxxxxxxxxxxx
Cc: 'Erik Andersen'
Emne: RE: [x500standard] Re: SV: Re: SV: Re: SV: Re: New defect report on
missing organisation information
David, Erik,
IANA registration is the natural IETF approach to handling extensions.
Because the X.500 and LDAP schema use OIDs, there is a framework for
non-conflicting vendor/user extensions (unlike the typical X- provision of
Internet standards).
This extensibility is vital for a huge number of directory deployments. It
also means that there is no requirement to standardize every single option.
I think that it was a very good X.500 design choice to include some standard
schema. The IETF have also built on this (such as inetOrgPerson in RFC
2798). There are some "obvious" gaps. For example, the inability to
associate an email address with any object other than a person.
The change in question seems sensible, although I did not think of vital
importance.
I suspect that there are a number of common schema changes that many
organizations/deployments make, where it would be preferable to have a
standardized schema.
I'd like to see this as an effort that revisits both X.500 and LDAP standard
schema, and gives a refresh of the "core", rather than this single isolated
change.
Regards
Steve
> -----Original Message-----
> From: x500standard-bounce@xxxxxxxxxxxxx [mailto:x500standard-
> bounce@xxxxxxxxxxxxx] On Behalf Of David Chadwick
> Sent: 01 April 2012 13:35
> To: x500standard@xxxxxxxxxxxxx
> Cc: Erik Andersen
> Subject: [x500standard] Re: SV: Re: SV: Re: SV: Re: New defect report
> on missing organisation information
>
> Hi Erik
>
> because we do not have a functioning attribute registry, then you have
> chosen the defect report as a workaround. An attribute registry, along
> the lines of the various registries run by IANA, would have been a
> valuable service for X.500 to have given the world two decades ago.
> But I dont see it happening anytime soon, so I support your defect
> report route as a way of getting an internationally recognised and
> supported attribute into the standard. Each country is entitled to
> vote on this, and if there is sufficient support then the new
> attribute will be added to the standard. If most countries reject the
> defect report then you will know that the attribute does not have
> sufficient support internationally
>
> regards
>
> David
>
>
> On 31/03/2012 12:14, Erik Andersen wrote:
> > Hi Sharon,
> >
> > Nice to have you back. I have been missing your for a long time.
> >
> > We do not have a clear issue here. It is true that if you have
> > control of an OID branch, you can define your own attribute types.
> > This one of the great feature of the OID concept. However, it is
> > also at times causes a disarray. As an example, LDAP has the concept
> > of controls where a control is assigned an OID. This has caused a
> > large number of controls to be defined in very diverted parts of
> > the OID tree, which makes it difficult to get a total picture about
> > what useful controls that are available. Often they are allocated
> > from company branches, companies that may not exist tomorrow.
> >
> > You could say the same about certificate extension. An uncontrolled
> > development of extension is against the spirit of standardisation
> > and causes interworking problems.
> >
> > If an organisation needs an attribute type that is very specific to
> > the organisation, it is reasonable that they use some odd OID.
> > However, if we talk about an attribute type that is general useful,
> > it is not very productive if everyone defines their own version of
> > that attribute type with different OIDs. I believe this is the case
here.
> >
> > We do not have good procedures for handling this case. A four years
> > cycle is not the optimal solution. We have to be a little flexible here.
> > By putting it up as a defect report people have the opportunity to
> > discuss whether a suggested attribute type is in fact general
> > useable or whether it is specific to a particular organisation.
> >
> > Kind regards,
> >
> > Erik
> >
> > *Fra:*x500standard-bounce@xxxxxxxxxxxxx
> > [mailto:x500standard-bounce@xxxxxxxxxxxxx] *På vegne af *Sharon
> > Boeyen
> > *Sendt:* 30. marts 2012 18:59
> > *Til:* x500standard@xxxxxxxxxxxxx
> > *Emne:* [x500standard] Re: SV: Re: SV: Re: New defect report on
> > missing organisation information
> >
> > Erik I agree with Denis that this is an enhancement and not a defect.
> > The standard allows other attributes to be defined by any entity.
> > The fact that in SOME environments an additional attribute would be
> > helpful does not make this a defect in the standard, but rather a
> > potential enhancement.
> >
> > *From:*x500standard-bounce@xxxxxxxxxxxxx
> > <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> > [mailto:x500standard-bounce@xxxxxxxxxxxxx] *On Behalf Of *Erik
> > Andersen
> > *Sent:* Friday, March 30, 2012 12:07 PM
> > *To:* x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>
> > *Subject:* [x500standard] SV: Re: SV: Re: New defect report on
> > missing organisation information
> >
> > HI Denis,
> >
> > I will give it a shot.
> >
> > Erik
> >
> > *Fra:*x500standard-bounce@xxxxxxxxxxxxx
> > <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> > [mailto:x500standard-bounce@xxxxxxxxxxxxx]
> > <mailto:[mailto:x500standard-bounce@xxxxxxxxxxxxx]> *På vegne af
> > *denis.pinkas@xxxxxxxx <mailto:denis.pinkas@xxxxxxxx>
> > *Sendt:* 30. marts 2012 18:01
> > *Til:* x500standard@xxxxxxxxxxxxx
> > <mailto:x500standard@xxxxxxxxxxxxx>
> > *Emne:* [x500standard] Re: SV: Re: New defect report on missing
> > organisation information
> >
> > Erik,
> >
> > You speak of VAT-number while others were speaking of something else.
> > I have the feeling that we have a solution but that we don't know
> > what the problem is or that we don't agree that we share the same
> > problem.
> >
> > We should start by a problem statement, which currently is far from
> > crystal clear.
> >
> > Proposing an ASN.1 syntax without the explanations is not the
> > solution either.
> >
> > The defect report is currently not correctly presented and would
> > need to be fully rewritten.
> >
> > Denis
> >
> >
> >
> >
> > De : "Erik Andersen" <era@xxxxxxx <mailto:era@xxxxxxx>> A :
> > <x500standard@xxxxxxxxxxxxx <mailto:x500standard@xxxxxxxxxxxxx>>
> > Date : 30/03/2012 17:51
> > Objet : [x500standard] SV: Re: New defect report on missing
> > organisation information Envoyé par :
> > x500standard-bounce@xxxxxxxxxxxxx
> > <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> >
> > --------------------------------------------------------------------
> > ----
> >
> >
> >
> >
> > Hi Denis,
> >
> > Thanks for making the effort to read the defect report and for the
> > correction. I am not used to that.
> >
> > There is no clear border line between a defect report and an
> > enhancement. Added a single attribute type has no affect on the
> > remaining of the specification and is therefore quite safe. I did
> > not invent the requirement for the new attribute type, but
> > recognised that we have been missing such an attribute type for a
> > long time to enter e.g. a VAT-number. The lack of such a capability
> > could be labelled as an omission, which is one of the things that can
justify a defect report.
> >
> > The seventh edition of X.520 is at its final stage where it is not
> > possible to add such an attribute as part of the extension process,
> > and if we tried, we would sneak it in. Now, we do it more openly.
> > Waiting for a possible eight edition of X.520 would delay the
> > solution by four years.
> >
> > The proposed solution will eventually end up in a Draft Technical
> > Corrigendum, that will go out for vote within both ISO and ITU-T.
> >
> > Erik
> >
> >
> > *Fra:*x500standard-bounce@xxxxxxxxxxxxx
> > <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> > [mailto:x500standard-bounce@xxxxxxxxxxxxx] *På vegne af
> > *denis.pinkas@xxxxxxxx <mailto:denis.pinkas@xxxxxxxx>*
> > Sendt:* 30. marts 2012 17:00*
> > Til:* x500standard@xxxxxxxxxxxxx
> > <mailto:x500standard@xxxxxxxxxxxxx>*
> > Cc:* Directory list*
> > Emne:* [x500standard] Re: New defect report on missing organisation
> > information
> >
> > Hummm !
> >
> > The "defect" is presented this way:
> >
> > The organizationName is not always enough to identify a
> > organisation. At times an additional information necessary, like
> > some kind of identifier issued by the authorities.
> >
> >
> >
> >
> > First of all, the sentence is not English. At the minimum a verb is
> > missing in the second sentence.
> >
> > But more important, I disagree that it is a "defect report". It
> > looks like an enhancement.
> >
> > Then, the "pseudo defect" is not correctly characterized.
> >
> > So if the question is not correctly stated, how could any solution
> > be appropriate ?
> >
> > Denis
> >
> >
> >
> >
> > De : "Erik Andersen" <era@xxxxxxx <mailto:era@xxxxxxx>> A :
> > "Directory list" <x500standard@xxxxxxxxxxxxx
> > <mailto:x500standard@xxxxxxxxxxxxx>>
> > Date : 30/03/2012 14:41
> > Objet : [x500standard] New defect report on missing organisation
> > information Envoyé par : x500standard-bounce@xxxxxxxxxxxxx
> > <mailto:x500standard-bounce@xxxxxxxxxxxxx>
> >
> > --------------------------------------------------------------------
> > ----
> >
> >
> >
> >
> >
> > I have issued a new defect report 381. See
> > http://www.x500standard.com/index.php?n=Ig.DefectReports
> >
> > Any comments?
> >
> > Erik
> >
>
> --
>
> **********************************************************
> *******
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security School of Computing,
> University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick@xxxxxxxxxx
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site:
> http://www.cs.kent.ac.uk/research/groups/iss/index.html
> Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
>
> **********************************************************
> *******
> -----
> www.x500standard.com: The central source for information on the X.500
> Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
