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

["Hoyt L. Kesterson II" <hoytkesterson@earthlink.net>]

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

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? i 
want to be sure that these are not attribute OIDs you are talking 
about

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?

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/DraftTechnicalCorrigend
> a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.doc
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
> a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.pdf
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
> a/closing26Feb2002/6N12081X.520DTC-3%284th%29.doc
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
> 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/AllDefect
> Reports/DR_287.pdf
>
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefect
> Reports/DR_288.pdf
>
>    hoyt