RE: RE: DTCs against X.520 / 9594-6

["Steven Legg" <steven.legg@adacel.com.au>]

Hoyt,

Hoyt L. Kesterson II wrote:
> sorry, forgot to copy to all recipients
>
>
> Date: Fri, 8 Feb 2002 00:34:55 -0700
> To: <steven.legg@adacel.com.au>
> From: "Hoyt L. Kesterson II" <hoytkesterson@earthlink.net>
> Subject: RE: DTCs against X.520 / 9594-6
> Cc:
> Bcc: "?:Directory:Defects"
> X-Attachments:
>
> hi steven
>
> ok, i plea total confusion here. TelephoneNumber is a type that is
> identical to PrintableString

It is not identical because it has both an actual constraint, i.e.

	(SIZE(1..ub-telephone-number))

and a notional constraint, i.e.

	-- String complying with ITU-T Rec. E.123 only

making it different from a vanilla PrintableString. LDAP reflects that
difference by assigning different syntax OIDs to the two types. Knowing
that a string is a telephone number rather than an arbitrary string of
characters allows one to do interesting things like call connection in
the DUA.

>
> is this a thing where ldap has assigned OIDs to syntaxes? and even
> though the universal type is the same, it would be handy to align
> with the specific type specified in the type assignment statement?

Yes. I support both LDAP and X.500 so I have a requirement to translate
between LDAP syntax OIDs and the ASN.1 types of X.500 attribute and
assertion syntaxes. A one-to-one mapping between the two makes things
easier for me. With the current definitions, an attribute or assertion
syntax of PrintableString could map into either the LDAP Telephone Number
syntax, 1.3.6.1.4.1.1466.115.121.1.50, or the LDAP Printable String syntax,
1.3.6.1.4.1.1466.115.121.1.44, depending on the attribute type or matching
rule. It would be much better if TelephoneNumber were used instead of
PrintableString in all cases of the former.

> i
> want to be sure that these are not attribute OIDs you are talking
> about

That's right.

>
> i don't have a problem with specifying TelephoneNumber in both
> places. However, if we are going to do that, should we amend the
> asn.1 definition of TelephoneNumber to constrain to the characters
> allowed in E.123?

You could. It may also be possible to formally constrain the format
to be E.123 using the new PATTERN constraint of ASN.1. However, the
most important thing for me is a one-to-one mapping between LDAP syntax
OIDs and ASN.1 types. I don't mind if the constraints are specified
only in ASN.1 comments, provided the constrained type has a distinct
name.

Regards,
Steven

>
> if we agree on this, i'll need some country to put it on their ballot
> for the dtc.
>
>    hoyt
>
> >Hoyt,
> >
> >Hoyt L. Kesterson II wrote:
> >  > Although I had put the DTCs against X.520 / 9594-8 up on the
> >  > server, I neglected to announce them. The ballots on the DTCs
> >  > close 27 February.
> >  >
> >  > The DTCs clarify the handling of an attribute with a
> >  > NamedBitList syntax and add the definition of a matching rule
> >  > for facsimile number. There are two DTCs - one against the
> >  > 3rd edition, the other against the 4th.
> >
> >With regard to the matching rule for facsimile number, would it
> >not be more appropriate for the assertion syntax for
> >facsimileNumberMatch (and likewise for telephoneNumberMatch) to
> >be TelephoneNumber rather than PrintableString ?
> >
> >This would align better with LDAP where the assertion syntax for
> >telephoneNumberMatch is the same as the attribute syntax for
> >telephoneNumber (i.e. 1.3.6.1.4.1.1466.115.121.1.50, corresponding
> >to the TelephoneNumber ASN.1 type). The Printable String syntax
> >in LDAP is distinctly separate and has the identifier
> >1.3.6.1.4.1.1466.115.121.1.44.
> >
> >Regards,
> >Steven
> >
> >  >
> >  > They can be found on the server in Word and PDF formats at
> >  >
> >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTec
hnicalCorrigend
>a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.doc
>
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen
d
>a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.pdf
>
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen
d
>a/closing26Feb2002/6N12081X.520DTC-3%284th%29.doc
>
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen
d
>a/closing26Feb2002/6N12081X.520DTC-3%284th%29.pdf
>
>The DTCs correct defect reports 287 and 288. They can be found at
>
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefec
t
>Reports/DR_287.pdf
>
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefec
t
>Reports/DR_288.pdf
>
>    hoyt