I like your proposal to use the term "keywords", instead of enums and tokens.
Tom
At 08:55 03/20/97 PST, Scott Isaacson wrote:
>>From our discussion yesterday on the IPP telecon call, it became
>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@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
>
>
>
>