Hi Phil,
Thanks for the feedback and the suggestion.
These specs have undergone interop testing among half a dozen or more (perhaps 10) independent implementations for over a year and a half now. Some of the implementors use available ASN.1 compilers; others, perhaps, are using hand-coding. But in any case, I've been assuming that if there were problems with the syntax it would have been brought to my attention long before now. It looks like either no one has encountered any problems, or no one has bothered mentioning it to me.
If you (or anyone else reading this) would like to run the modules through a syntax checker and give me a list of the necessary changes, I'd be happy to incorporate them. My sense, however, from what you've listed below, is that the changes required will be sufficiently minor that they can all be taken care of during the last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. Therefore, I see no reason to hold up progression of either of these documents.
Carlisle.
----------
From: Phillip H. Griffin[SMTP:phil.griffin@xxxxxxxxx]
Reply To: phil.griffin@xxxxxxxxx
Sent: Friday, March 02, 2001 12:51 PM
To: Carlisle Adams
Cc: ietf-pkix@xxxxxxx; 'ca-talk@xxxxxxxx'
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
Petty perhaps, but it might be nice to review
this ASN.1 rigorously before any progression.
Just browsing through the -03 version I found
some busted notation. The named integer values
"CMP1999(1), CMP2000(2)" should begin with lower
case letters.
And "implicitConfirm ::= {id-it 13}" should be
"implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
and "implicitConfirmValue ::= NULL" is invalid as
well.
A good going over by an automated syntax checker
tool such as one of the freely available ones at
http://www.oss.com/products/syntax1.html or listed on
http://asn1.elibel.tm.fr/en/links/index.htm#tools
would probably find some things that I missed by eye.