Draft: draft-lilly-text-troff-03
Review: Elwyn Davies 
Date: 20 maj 2005 

Document: draft-lilly-text-troff-03.txt
Trigger: IESG telechat 26 May 2005
Reviewer: Elwyn Davies
AD: Thomas Narten
Review Date: 20 May 2005

Intended status: Informational

Review Parameters: This is a review by a member of the General Area
Reviewing team, supporting the IETF General Area Director. This
document is an Individual Submission via an AD and hence the review
focusses on these questions: 

"Is this document a reasonable contribution to the area of Internet
engineering which it covers? 
If not, what changes would make it so?"

Review:
I am somewhat amused by the arrival of a document to recommend a
'standard' for transmitting troff/nroff in emails at this late
juncture. With luck and a following wind it will appear as an RFC just
in time for the 30th anniversary of the publication of the troff
manual cited in the references. A 'Pearl' of wisdom as an anniversary
gift indeed! 

Droleries aside, 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.