On Thu March 3 2005 21:32, Bill Fenner wrote: > > Sect. 2 mentions the "instructions > > to RFC Authors" document; that should probably refer (instead or > > additionally) to RFC 2223 or its successor (which the named > > document is apparently intended to become). > > The draft says 'This format is specified fully in "instructions to RFC > Authors" (see the RFC Editor's Web pages and > [I-D.rfc-editor-rfc2223bis]).' - is the reference there not the one > you're suggesting? It's a matter of either having a stable reference (e.g. a published RFC) or referring to something subject to change as a "work in progress". At least that's what would be expected if the document were itself an Internet-Draft or RFC. > > An error was made in > > conversion of "10 inches" -- the text "less than about 250mm" > > should be replaced with "no greater than 254.00mm". > > I did say "about". I didn't think that the 4mm was particularly > important; maybe I'm just remembering how stupid I thought it read > when a book I was reading said "...about 621.37119 miles" when it was > converted from "about 1000 kilometers". The problem is that it's not clear how to interpret "less than about". Clearly 254mm was allowed (exactly equal to 10 in.); is that "less than about 250mm"? What about 254.1mm (> 10 in.)? > > How about > > "Internet Draft" rather than the HYPHENATED-SHOUTING > > "INTERNET-DRAFT"? > > I don't mind removing the shouting, but the hyphenation is on purpose. > Internet-Draft is meant to be a noun. OK. (note however that a number of recent drafts (not just mine) lack the hyphen) > > There is a discussion about restrictions on > > content of the title -- RFC 2223 has text prohibiting a dot in > > the title > > rfc2223bis doesn't have this restriction. However, it's worth > including 2223bis's restriction on acronyms. Good about the dot (considering that there in fact have been RFCs with 802.3 etc. in titles). > I copied the boilerplate in sections 3 and 4 from the lawyer-approved > text in RFC 3978. I'm not inclined to change it without advice from > the lawyer (which I'm becoming convinced that I should seek - you're > not the only one who wants to vary the text.) At the same time, could you ask if it's possible to make the text more concise. It's difficult to fit a meaningful Abstract on page 1 so that the TOC can be placed on page 2 (as specified in 2223) with boilerplate as verbose as it is (of course that's not all due to legalese). > > 1. I'd like to see a statement that spaces around "(C)" are > > optional and that PostScript and PDF versions may use the > > copyright symbol in place of a parenthesized C. > > Do you mean that "Copyright(C)The Internet Society" is acceptable? Yes. The reason is that when preparing both text and formatted versions with the same line and page breaks, both versions need to have the same number of characters. In the case of formatted documents, that's <SP><copyright><SP> -- three characters. Now it would be possible to retain the spaces in the text version if the formatted version has <SP><SP><copyright><SP><SP> -- five characters -- but that looks weird. Breaking consistency usually wouldn't be a problem on page 1, since the copyright line stands alone (ergo, line and page breaks are unaffected). But it can cause strange inconsistencies at the end, where it's followed by "This document is subject to [...]". > > 2. Presumably the draft should not literally contain the > > characters "(year)" > > Indeed, that's why the document says 'The "year" in the copyright > statement should be replaced with the current year.'. Can you suggest > a way to make this more clear? Maybe an example? Maybe it would be clearer with "YYYY" instead of the word "year"? Maybe both (example and YYYY)? > > Section 4, paragraph labeled a raises some amusing issues > > Again, these are RFC 3978 issues. 1id-guidelines is reflecting the > ipr policies, not making them. The draft update to 2223 states that RFCs are in English (2223 itself does not), but there doesn't seem to be any such requirement for drafts. Maybe there should be one (otherwise, we may need different boilerplate). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf