I-D ACTION:draft-lilly-text-troff-00.txt; registration vs. other specifications

[blilly at erols.com (Bruce Lilly)]

There have been a number of comments specifically related to
security matters.  As mentioned, I believe security issues are
covered in the draft text in the Security Considerations of
the registration template which comprises a significant part
of the draft, and the separate Security Considerations section
of the draft per se, which refers back to the section in the
registration template.

One of the considerations that went into the writing of the draft
is the distinction between registration of the media subtype vs.
other specifications.  One issue is that with security matters
one would like to use BCP14 (a.k.a. RFC 2119) keywords, but that
hardly seems appropriate for mere registration.  And the sole
purpose of the draft is to register the media subtype.  There
are a few instances of RFC 2119 language in the registration
template in the draft, and that makes me slightly uneasy. Short
of some authoritative indication that BCP14 language is appropriate
in a registration template, I would not be inclined to further
increase use of those keywords.

If those who have commented on security-related matters still
feel that the discussion in the draft is inadequate, I could
repeat the material outside of the registration template and use
suitable RFC 2119 keywords there.  However, that leaves the
issue of the eventual status of the document, as well as the
issue of lack of enforcement mechanisms.  The draft is an
individual submission; as I understand the procedures, there
are two paths for it to publication as an RFC:
1. as an individual submission via the RFC Editor, in which
   case there is likely to be an IESG note disclaiming any
   knowledge of fitness for any purpose (RFC 3932).
2. by a request to the IETF for review and publication as
   an RFC.  Publication by this route would certainly require
   some AD action. Most likely the category would be Informational,
   which is off the standards track, i.e. "does not specify
   an Internet standard of any kind".  I believe that
   category would suffice for the purpose of registering the
   media type, and that is the category that I would request.
In either case, it's slightly unclear what practical effect, if
any, presence of RFC 2119 language would have.  RFC 2119's
Abstract specifically mentions standards track documents, but
also mentions more generic "IETF documents"; it also notes
"that the force of these words is modified by the requirement
level of the document in which they are used".  My understanding
is that "requirement level" is something that would be specified
in an Applicability Statement, which would be a separate document
from the Technical Specification of the media subtype.

My reading of the proposed revision to the media type registration
procedure (draft-freed-media-type-reg-01) is that route #1 above
would be prohibited for registration in the Standards Tree (i.e.
under text) as it is not approved by the IESG ("Registrations in
the standards tree MUST be approved by the IESG [...]").  There
is a similar passage in RFC 2048, but the tree itself is therein
referred to as the "IETF Tree".

In light of all of the above, I would like to ask if those who
have raised issues are satisfied with the draft text, and if not
what specifically do they propose as a solution consistent with
the considerations above and as previously discussed.

Some clarification of the intent of the registration procedures
documents w.r.t. RFC Editor vs. IETF paths, and of suitability of
BCP14 language within the registration template might also be
helpful, as would comments from the Applications Area ADs regarding
applicable procedures and policies.