very clear that our use of term "enum" has been problematic. This
is due to the following:
1. Enums in most languages and SNMP turn out to be integers
2. Enum was left out of the basic syntax table
3. Token was used but inconsistently to mean kind of the same thing
4. Attribute names themselves where never given any syntax
I am afraid that no matter what term we use to fix it there will still be
some confusion, but I am certain that the following plan of attack will
help. I am in the process of editing the whole document
right now to do the following:
1. Introduce a basic new syntax type called "keyword" This replaces all notions of enum
and token This is a string of characters (1:255)
letters, "-", and "_".
2. Attribute names themselves are keywords
3. Some attributes have syntax of "setOf Keyword"
4. Sets of keywords are type1, type2, or type3
5. Notice then that the set of attribute names for IPP are just
a type2 setOf keywords (exetnsible as any other type2 keyword set)
We need bring notion of extensibility up to the front of the document as
Tom suggests. I have already moved most of the other conformance stuff up front as well.
Scott
>>> Tom Hastings <hastings at cp10.es.xerox.com> 03/20/97 01:51am >>>
I was surprised by the debate today about whether attributes
themselves could be registered like type2enums.
I found the following sentence in Section 6 Conformance,
page 62, lines 1585-1591:
IPP is explicitly designed to be extensible. Additional attributes can be
proposed to be registered by going through the type 2 enum process which
will register their specification after approval with IANA. In addition
specific implementation instances may support not only the basic protocol as
defined in this specification, but may add vendor-specific private
extensions by prefixing attribute-names with their company name registered
with IANA for use in domains. See attribute syntax section. However, such
private extensions shall not duplicate attribute semantics already in this
specification.
Open issue 22, seeks to move this part of the conformance section
up front, since it is such an important feature of IPP and is
what will prevent the disaster with LPR/LPD that every manufacturer
extended it in different uncontrolled ways. We need to show the
IETF that we have a solution.
We must do issue 22 for the Internet-Draft so that the readers
will see it.
Thanks,
Tom