On Tue, 15 Feb 2022 16:04:07 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> > > ```
> > > 2. I feel a little uneasy of the new `if` and `otherwise` words inside
> > > parentheses, especially the second one which seems out of nowhere. Please
> > > suggest better wording if possible.
> > > ```
> >
> >
> > What about?
> > ```
> > and a fourth entry as either a string if {@code value} inside
> > is a valid ASN.1 string (any of UTF8String, PrintableString, T61String,
> > IA5String,
> > UniversalString, BMPString, or GeneralString) or otherwise a byte array
> > containing
> > the ASN.1 DER encoding of {@code value} without the context-specific
> > constructed tag with number 0.
> > ```
>
> Do not feel easy with the two `or`.
Yes, then you need parens...
> > > ```
> > > 3. The string types I listed is only what we supported inside JDK and not
> > > all "restricted character string types". Is it appropriate to list them
> > > out in a specification? If not, shall I just say "a valid character
> > > string"? This brings more explanation to what "valid" means.
> > > ```
> >
> >
> > Yes, this makes it perfectly clear what is supported of out of the box.
>
> But this also means if the internal implementation deep inside
> `DerValue::getAsString` is updated then this spec must be updated as well.
True, it creates an unnecessary dependency. Remove explicit mentioning. I don't
expect any new ASN.1 string types to be added in the future, but of someone
decides to create a public ASN.1 API in the JDK and rewrite all internal code
this would be subject to it.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7167
