Ron and Gary,
About indenting by 3 spaces (we've never done it for IPP drafts, but the RFC
editor went to the trouble of changing the text for us and inserting the
three leading spaces). So doing it ahead of time will help get things done
faster, I would assume.
You could redefine the plain text style to be indented 3 spaces. However,
you'd want to introduce another style for the actual MIB which doesn't want
to be intended. Also in the text portion there are several excerpts from
other MIBs that already have leading spaces and will cause line wrap if they
are indented an additional 3 spaces for the plain text style.
So may if the plain text styles for MIB data is changed to some new style,
say, mib, which doesn't have the indent, that it will be straightforward.
Tom
-----Original Message-----
From: Gocek, Gary [mailto:GGocek@crt.xerox.com]
Sent: Thursday, August 03, 2000 11:32
To: 'Ron Bergman'
Cc: pmp@pwg.org
Subject: PMP> RE: Comments on draft-ietf-printermib-mib-info-05.txt
Without having actually opened the document for editing, I'd say that these
items look do-able, to be released next week, after the 'last call' period
ends.
Gary Gocek, Xerox Corp.
> -----Original Message-----
> From: Ron Bergman [mailto:rbergma@hitachi-hkis.com]
> Sent: Wednesday, August 02, 2000 9:45 PM
> To: ggocek@crt.xerox.com
> Cc: pmp@pwg.org
> Subject: Comments on draft-ietf-printermib-mib-info-05.txt
>
>
> Gary,
>
> Although the following items do not affect the technical
> content of the MIB, they may result in a delay when the
> document is reviewed by the IESG or the RFC editor. I
> would classify all as "nice to have" in the next draft.
>
> 1. You should add your name to the authors section and
> to the cover page. Especially since you completed the
> final push to get the document completed!
>
> 2. The table of contents should be single spaced. I checked
> several other documents and could not find any with other
> than a single spaced table of contents.
>
> 3. There references to the IPP specifications in chIPP(44),
> as indicated using square brackets. The corresponding
> entries are not in the references section (section 10),
> but rather included at the end of this Textual
> Convention entry. It would be best to move these to
> section 10. One of the comments on the Job MIB was there
> was too much specification type information in the
> comments section of the MIB. This TC entry has over 2
> pages of specification in the comments!
>
> 4. Some of the references in chIPP(44) do not have square
> brackets and should be changed. For example, "see RFC
> 2565/2566" S/B "see [RFC2565] and [RFC2566]".
>
> 5. RFCs are presently indicated in three different ways;
> RFC XXXX, RFCXXXX, and RFC-XXXX. From the review of
> other documents, it appears that the format RFCXXXX is
> used as a pointer to the references section and otherwise
> the RFC XXXX is used. Consistency is most important and
> presently that is missing.
>
> 6. This is the BIG one! IETF standards require that the
> text that follows the lines with paragraph numbers be
> indented by three characters. RFC 1759 was formatted
> per this requirement. I am not sure if this is a task
> that the RFC Editor will assume or will he pass the
> document back to the WG Editor. (Note that this does
> not affect the MIB body, but it still a major task.)
> We could submit as is and see if it is accepted.
>
> 7. Added by Gary G as a reminder: Check for 65 char margins
> early in doc. 72 is correct and is used after the TOC.
>
>
> Ron Bergman
> Hitachi Koki Imaging Solutions
This archive was generated by hypermail 2b29 : Fri Aug 04 2000 - 19:53:53 EDT