[x500standard] Re: SV: Re: SV: Re: SV: Re: SV: Re: New defect report on missing organisation information
- From: "Steve Kille" <steve.kille@xxxxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 2 Apr 2012 12:18:02 +0100
Erik,
I think that doing a formal process will be too much work.
A group of informed people making updates to the core using common sense and
experience would be useful in my view
Regards
Steve
> -----Original Message-----
> From: x500standard-bounce@xxxxxxxxxxxxx [mailto:x500standard-
> bounce@xxxxxxxxxxxxx] On Behalf Of Erik Andersen
> Sent: 02 April 2012 11:32
> To: Directory list
> Subject: [x500standard] SV: Re: SV: Re: SV: Re: SV: Re: New defect report
on
> missing organisation information
>
> 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.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
