[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-sming-reqs-03.txt
Jon> [...] If I thought that adding semicolons at the end of
Jon> each line or changing the capitolization rules would advance the
Jon> state of management, I would be be all for them. I just have not
Jon> been convinced that they will.
This doesn't belong directly to the requirements discussion, but I'd
like to explain why we introduced the semicolon (back early in the
NMRG SMIng work).
We had the goals in mind to
- design the language so that it's human readable (in the `human ==
programmer' sense, that might be a wrong assumption ;-)),
- design the language so that it's easy to implement parsers, since
today we suffer a lot from a variety of bad parsers,
- design the language so that it's extensible in a way that language
extensions (either standardized some day, or vendor specific, or
user specific) are parsable or can be skipped if unknown.
These three goals are listed in the current requirements draft.
We found that the general concept of
- statements being introduced by a keyword,
- statements being terminated by a semicolon,
- 0, 1, or more arguments to the statement inbetween the keyword and ;,
- the possibility to let an argument be another sequence of statements
is very familiar to many people, e.g., from programming languages like
C and Java. It's a question of how much we are willing to free our
minds from ASN.1 and open them to what people are familiar with *in
The same is true for writing keywords with lowercase letters in most