Here is my action item on the Model Section 6 IANA Considerations.
I've consulted with Bob Herriot and Carl-Uno on these proposed
simplfications. Please send any comments immediately.
I re-read the new IANA Considerations document
(draft-iesg-iana-considerations-01.txt) and see that we should make the
following changes in order not to hold up IPP in the IESG:
1. The model needs to assign IPP Subject Matter Experts by name, not position.
2. The document suggests chairs, so I've talked to Carl-Uno and he suggests
that Carl-Uno and Steve should be the IPP Subject Matter Experts.
3. The model needs to say who can find a replacement and suggests the A-Ds,
so I've added that and included that the PWG can change them too.
4. The model needs to say who maintains each entry. Type 2 should be the
PWG, type 3 should be the proposer.
5. Don't have IANA have to assign type 3 keywords and enums, lets have
the Subject Matter Experts do it.
So all IANA has to do for type 2 and type 3 is keep the approved
registrations (the document recommends delegation). This is what we
have done for the Printer MIB "printer language" registrations
(document formats).
Here is the complete new text for section 6. (only 6.1 has changed).
I've also posted a .doc (WORD 6) and a .pdf file to show the revisions:
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.docftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-iana-considerations.pdf
6. IANA Considerations (registered and private extensions)
This section describes how IPP can be extended.
6.1 Typed Extensions
IPP allows for "keyword" and "enum" extensions (see sections 4.1.5 and
4.1.6). In reviewing proposals for such extensions, the IPP Subject Matter
Experts are: Carl-Uno Manros (manros at cp10.es.xerox.com) and Steve Zilles
(szilles at Adobe.com). If a replacement is needed, the IESG Applications
Area Director, in consultation with the PWG [PWG] using pwg at pwg.org, SHALL
appoint a replacement. The PWG can also specify a replacement at any time.
This document uses prefixes to the "keyword" and "enum" basic syntax type
in order to communicate extra information to the reader through its name.
This extra information need not be represented in an implementation because
it is unimportant to a client or Printer. The list below describes the
prefixes and their meaning.
"type1": The IPP standard must be revised to add a new keyword or a new
enum. No private keywords or enums are allowed.
"type2": Implementers can, at any time, add new keyword or enum values by
proposing the specification to:
- the IPP working group (IPP WG using ipp at pwg.org) while it is still
chartered, or
- the Printer Working Group [PWG] using pwg at pwg.org after the IPP working
group is disbanded
who will review the proposal and work with IANA to register the additional
keywords and enums.
For enums, the IPP WG or PWG assigns the next available unused number.
When a type 2 keyword or enum is approved by the IPP WG or PWG, the PWG
becomes the point of contact for any future maintenance that might be
required for that registration.
IANA keeps the registry of keywords and enums as it does for any registration.
"type3": Implementers can, at any time, add new keyword and enum values by
submitting the complete specification directly to the IPP Subject Matter
Experts. While no IPP working group or Printer Working Group review is
required, the IPP Subject Matter Experts may, at their discretion, forward
the proposal to the IPP WG or PWG for advice and comment.
For enums, the IPP Subject Matter Experts assigns the number for enum
values. and keeps the registry of keywords and enums.
When a type 3 keyword or enum is approved by IPP Subject Matter Experts,
the original proposer becomes the point of contact for any future
maintenance that might be required for that registration. IANA keeps the
registry of keywords and enums as it does for any registration.
"type4": Anyone (system administrators, system integrators, site managers,
etc.) can, at any time, add new installation-defined values (keywords, but
not enum values) to a local system. Care SHOULD be taken by the
implementers to see that keywords do not conflict with other keywords
defined by the standard or as defined by the implementing product. There is
no registration or approval procedure for type 4 keywords.
Note: Attributes with type 4 keywords also allow the 'name' attribute
syntax for administrator defined names. Such names are not registered.
By definition, each of the four types above assert some sort of registry or
review process in order for extensions to be considered valid. Each higher
level (1, 2, 3, 4) tends to be decreasingly less stringent than the
previous level. Therefore, any typeN value MAY be registered using a
process for some typeM where M is less than N, however such registration is
NOT REQUIRED. For example, a type4 value MAY be registered in a type 1
manner (by being included in a future version of an IPP specification)
however it is NOT REQUIRED.
This specification defines keyword and enum values for all of the above
types, including type4 keywords.
For private (unregistered) keyword extensions, implementers SHOULD use
keywords with a suitable distinguishing prefix, such as "xxx-" where xxx is
the (lowercase) fully qualified company name registered with IANA for use
in domain names [RFC1035]. For example, if the company XYZ Corp. had
obtained the domain name "XYZ.com", then a private keyword 'abc' would be:
'xyz.com-abc'.
Note: RFC 1035 [RFC1035] indicates that while upper and lower case letters
are allowed in domain names, no significance is attached to the case. That
is, two names with the same spelling but different case are to be treated
as if identical. Also, the labels in a domain name must follow the rules
for ARPANET host names: They must start with a letter, end with a letter
or digit, and have as interior characters only letters, digits, and hyphen.
Labels must be 63 characters or less. Labels are separated by the "."
character.
For private (unregistered) enum extension, implementers SHALL use values in
the reserved integer range which is 2**30 to 2**31-1.
6.2 Registration of MIME types/sub-types for document-formats
The "document-format" attribute's syntax is 'mimeMediaType'. This means
that valid values are Internet Media Types. RFC 2045 [RFC2045] defines the
syntax for valid Internet media types. IANA is the registry for all
Internet media types.
6.3 Attribute Extensibility
Attribute names are type2 keywords. Therefore, new attributes may be
registered and have the same status as attributes in this document by
following the type2 extension rules.
6.4 Attribute Syntax Extensibility
Attribute syntaxes are like type2 enums. Therefore, new attribute syntaxes
may be registered and have the same status as attribute syntaxes in this
document by following the type2 extension rules. The value codes that
identify each of the attribute syntaxes are assigned in the protocol
specification [IPP-PRO].