Media Subtype Registration for Media Type text/troff
Note: This ballot was opened for revision 04 and is now closed.
(Scott Hollenbeck) (was Discuss, Yes) Yes
(Brian Carpenter) No Objection
Comment (2005-05-20 for -)
(from Gen-ART review by Elwyn Davies) ...this document appears almost ready for publication. Clearly troff, nroff and their many relations are still hale and hearty and are in regular use (as we know only too well for RFCs) so that this is a useful document and appears to cover the area satisfactorily. There is one item which seems to need improvement and a couple of minor quibbles. Security Considerations: The second (and last) sentence states: "Additional considerations may apply in some contexts (e.g. MIME[I17.RFC2049])." This is a vague catch-all which I think needs some refinement. I also can't see the relevance of RFC2049.. maybe RFC2046 might be a better reference here? I can't suggest new text because I am unsure what the author means by it. A couple of quibbles: The lists of formatters and format converters in 'Applications which use this media type' may not be complete.. I can think of at least one other that has (and may still be around - I am not a xroff user these days) - psroff. Is this intended to be complete? or should it include something like '... and equivalent tools'? Appendix B: we appreciate that the author has objections to some of the legalistic flights of fancy that are required features of I-Ds and RFCs, but I would venture to suggest that the irony is misplaced here, and may even have been overtaken by events... the boilerplate moves faster than the I-D production process? Reference to RFC2048: The document should refer to and provide the relevant normative reference to RFC2048 which specifies the format of the registration form at the heart of the document.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) (was Discuss) No Objection
Bruce has suggest some text to update this text A command line, such as may be suggested via the optional "process" parameter, is a powerful tool when used by a computer-literate person. Individuals lacking basic security knowledge and/or common sense SHOULD NOT be given unsupervised access to a command line. Users of this media type SHOULD carefully scrutinize the suggested command pipeline and media content before executing commands. I'm fine with Bruce's text (sent in email), and Scott will hold the discuss until it has popped out.
(Sam Hartman) No Objection
Comment (2005-05-26 for -)
I'm dubious of the claim that application/* and image/* should be used for roff input that is pictorial or otherwise is not human comprehensible. I'm sure that's correct from a MIME purist standpoint although it seems problematic to have multiple media types for the same media.