Re: Upper Bounds for X.509

[Hoyt L Kesterson II <hoytkesterson@xxxxxxxxxxxxx>]

One minor clarification. Only the blue book (the original CCITT X.520 specification) identified the Bounds annex as normative. That was in error. When the corresponding ISO version was published (the first edition was not done as common text) in 1990 the Bounds annex was correctly identified as informative.

All subsequent publications (done as common text) contained the following line under the annex title — "This annex does not form an integral part of this Recommendation | International Standard"

The Foreword clause also contained this paragraph

"Annex C, which is not an integral part of this Recommendation | International Standard, provides suggested upper bounds value constraints used in these Directory Specifications."

Erik's phrase "expressed that Upper Bounds are only provided as examples" means that we have further emphasized that the values are not mandated by the standard. Next we will try blinking red text.

    hoyt


-----Original Message-----
>From: Erik Andersen <era@xxxxxxxxxx>
>Sent: Oct 19, 2007 7:19 AM
>To: PKIX <ietf-pkix@xxxxxxx>
>Subject: Upper Bounds for X.509
>
>Hi Folks,
>
> 
>
>As mentioned in a liaison statement from the directory meeting, September
>2007 in Geneva, we have decided to remove the Upper Bounds from any
>occurrence. A majority of those are on DirectoryString, which is also
>specified for many attribute types.
>
> 
>
>At one type we were considering removing the Upper Bound by the Defect
>Report procedure, but found the change to heavy for that procedure. By the
>Defect Report procedure we corrected a inconsistency in the Upper Bounds and
>expressed that Upper Bounds are only provided as examples.
>
> 
>
>It is our intention to remove the Upper Bound from the sixth edition of the
>Directory Specification. We gave a possible approach in the liaison
>statement, but that may not be the final solution. Be assured that whatever
>we do, it will be valid ASN.1. The example we came up with is actual valid
>ASN.1 by using parameterized specification. However, we are faced with the
>problem that directory object class definitions will be parameterized. This
>does not change the definition as such, but only the ASN.1 appearance. This
>could be a problem for implementations parsing such object class definitions
>to set-up the directory schema.
>
> 
>
>Our fall-back solution is to define a new variant of DirectoryString that is
>unbounded.
>
> 
>
>Erik Andersen
>
>Andersen's L-Service
>
>Mobile: +45 20 97 14 90
>
>e-mail: era@xxxxxxxxxx
>
>http://www.x500standard.com/
>
>http://home20.inet.tele.dk/era/me
>
> 
>