[rfc-i] RFC Editor Queue Contents

[julian.reschke at gmx.de (Julian Reschke)]

Kurt D. Zeilenga wrote:
> At 08:48 AM 1/14/2005, Julian Reschke wrote:
> 
>>Bob Braden wrote:
>>
>>>And your point was...?
>>
>>...that there are documents in the RFC Editor queue under "INDEPENDENT SUBMISSIONS UNDER RFC EDITOR REVIEW" in status ISR which since have been updated, and thus should either removed from the queue (if they are already in IESG processing) or have to re-enter the queue as new submissions.
> 
> 
> Some I-Ds were simply refreshed (no changes other than
> dates/revision number) by the author as they got removed
> of the repository due to 6 mo expiration.  I did this for
> at least one of my individual submissions (with note to RFC
> Editor).  And, I surely hope, that I do not lose my place
> in the queue simple for refreshing the I-D.
> 
> In other cases, it possible (though I am guessing here) that
> the RFC Editor asked the author to make some changes.  I don't
> see why such documents should lose there place in the queue
> either.
> 
> Also, I have no problem allowing authors to make minor editorial
> changes to I-Ds in the queue, as long as they coordinate those
> changes with the RFC Editor and the RFC Editor has no objection.
> This for the simple reason that it might save the RFC Editor
> later on (like during AUTH48).
> 
> Hence, I have to disagree that documents should, in general,
> be removed from the queue if updated.  I believe whether or not
> the updated document should be resubmitted or not is best left to
> the discretion of the RFC Editor.

Kurt,

seems that my report didn't come over as intended :-)

I absolutely agree that it's a good thing if minor fixes can be done 
while the document is sitting in the queue. Is this fact documented 
somewhere? (if it isn't it would be good if it was, and if the entries 
in the Queue document would reflect that somehow).

I was just concerned about things that appeared to me as a out-of-sync 
conditions between RFC-Editor and IETF (*), and to have an automated 
process that points out the discrepancies seemed like a good idea. It 
was neither my intention to step on anybody's toes, nor to have active 
entries removed from the queue that are in front of my own document.

Best regards, Julian


(*) For instance:

draft-haverinen-pppext-eap-sim-13.txt: newer document 
draft-haverinen-pppext-eap-sim-16 in status IESG

The Queue lists this document as:

   2004/04/06-I  draft-arkko-pppext-eap-aka-12.txt
   ISR
   J. Arkko, H. Haverinen
   Extensible Authentication Protocol Method for UMTS Authentication and
   Key Agreement (EAP-AKA)
   Bytes: 183977

...while the IETF I-D Tracker says 
(<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6702&rfc_flag=0>) 
it has been since submitted to the IESG (AD Thomas Narten), thus listing 
it as waiting for ISR (Independent Submission Review by the RFC Editor) 
seems to me indeed incorrect.


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]
From blilly at erols.com  Mon Jan 17 11:42:08 2005
From: blilly at erols.com (Bruce Lilly)
Date: Mon Jan 17 11:44:22 2005
Subject: [rfc-i] Re: request to deprecate numeric citations in ...
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

In rfc-interest Digest, Vol 11, Issue 4:
>  Date: 2005-01-12 23:05
>  From: John C Klensin <[e-mail]>
>  To: [e-mail]

> Although I've used numeric citations, I favor this change.
> However, I would encourage folks to think through two
> potentially unintended consequences:
> 
> (1) What converted me to numeric citations was the realization
> that there was no way to alphabetize mnemonic/text references if
> the references section itself was divided into two parts.

Indeed. From another perspective (writing nroff macros to
handle references),  it's easy, almost trivial, to be able
to automatically generate numerical reference numbers, even
if they're divided into N.1, N.2..., I.1, I.2... groupings.

Given the following three types of references:

1. numeric, possibly divided into groups, numbered per
   order of appearance in the text body
2. generic, presented in the index per order of
   appearance in the text body
3. generic, presented in the reference lists collated (i.e.
   without regard to order of appearance in the text body)

references of types 1 & 2 are fairly easy to generate automatically,
with #1 being somewhat easier (the length of the reference can
be guessed, and that affects hanging indents in the reference
section; with arbitrary strings, either they have to be collected
and measured to obtain a uniform hanging indent, or it requires
some manual massaging). References of type 3 definitely require
manual massaging or rather complicated processing.  So there's
something to be said in favor of numeric references.

> Now, one might use
> ? ? Normative references
> ? ? [N.Bozo95] ...
> ? ? [N.Clar97] ...
> ? ? Informative references
> ? ? [I.Rudo04]...
> but I don't think I've ever seen it in an RFC [...]

See Keith Moore's RFC 3834.

> (2) More generally, the names that are needed to make public
> entities unique are fairly nasty for symbolic references.
> [RFC9999] is fine, but [I-D.ietf-bozo-foo-bar-content] is fairly
> unpleasant.

Two editorial issues regarding non-numeric references:
1. [RFC9999] is OK as such, but some RFCs are also BCP, STD or FYI
   documents. For consistency, it would help authors to know how
   the RFC Editor prefers these to be indicated.  E.g. [BCP18]
   vs. [RFC2277].  This also relates to John's draft regarding
   BCP etc., draft-klensin-newtrk-std-repurposing-00.
2. For internet drafts, I would use something like an Author-Date
   reference, e.g. [Crocker04] to refer to draft-crocker-email-arch-01.

Regarding drafts in particular, while URL references are discouraged
because they might not be stable, in theory at least the RFC Editor
maintains I-D files, substituting a "tombstone" file when a draft is
published as an RFC or is abandoned. So reference to the detailed
file name might be possible via a URI pointing to the draft file
name in the reference text as opposed to trying to wedge it into
the reference string itself.  For such purposes, though, a symbolic
link from a name w/o the version number to the latest version would
be a convenience (the tombstone file usually has a version suffix
greater than the highest draft version).
From fenner at research.att.com  Thu Jan 20 09:08:13 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Jan 20 09:10:31 2005
Subject: [rfc-i] independent submissions to RFC Editor
Message-ID: <[e-mail]>


Sorry to dredge up an old thread, but I've been a bit out of it
for a week and wanted to contribute my database's view of the
comparison:

mysql> select rfcq.docname,rfcq.status from rfcq,all_id where all_id.docname=rfcq.docname and all_id.status='expired';
+---------------------------------------+------------------------------------+
| docname                               | status                             |
+---------------------------------------+------------------------------------+
| draft-paskin-doi-uri                  | ISR 6/30/03 (back to ISR after TO) |
| draft-cordell-lumas                   | ISR                                |
| draft-gpaterno-wireless-pppoe         | ISR re-evaluation                  |
| draft-shirasaki-dualstack-service     | ISR                                |
| draft-keri-local-anon                 | ISR                                |
| draft-holness-network-l2vpsp          | ISR                                |
| draft-park-dna-ipv6dadopt-requirement | ISR                                |
| draft-riikonen-silc-spec              | ISR                                |
| draft-riikonen-silc-pp                | ISR                                |
| draft-riikonen-silc-ke-auth           | ISR                                |
| draft-riikonen-flags-payloads         | ISR                                |
| draft-riikonen-presence-attrs         | ISR                                |
| draft-manning-opcode-discover         | ISR                                |
+---------------------------------------+------------------------------------+
13 rows in set (0.05 sec)

  Bill
From fenner at research.att.com  Thu Jan 20 09:21:19 2005
From: fenner at research.att.com (Bill Fenner)
Date: Thu Jan 20 09:22:26 2005
Subject: [rfc-i] RFC Editor Queue Contents
References: <[e-mail]> <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>


Sorry for my earlier post in the other thread that duplicated what
Julian said; I didn't see that the discussion had jumped threads.

>I was just concerned about things that appeared to me as a out-of-sync 
>conditions between RFC-Editor and IETF (*), and to have an automated 
>process that points out the discrepancies seemed like a good idea.

For mine, see http://rtg.ietf.org/~fenner/iesg/rfcq.html .  The IESG
and RFC-Editor get weekly emails about the red rows; the Secretariat
gets a weekly email about the orange ones.  If you're curious about
history you can check the file rfcq-YYYYMMDD.html back to 20020705.
(You may need to go back in time to find any red entries, since with
the periodic emails we're now in pretty good shape.)

I never figured out what to do about the ISR entries because the
IESG/RFC-Editor states are not very well synchronized in the ISR
state.

  Bill
From blilly at erols.com  Sat Jan 22 12:32:58 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Jan 22 12:34:07 2005
Subject: [rfc-i] Re: request to deprecate numeric citations in ...
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Mon January 17 2005 15:10, Keith Moore wrote:

> the two are not equivalent, because the BCP can change (point to a 
> revised document) whereas the RFC will not.  so the author should use 
> whichever one he means.  if he means "the current version of the IETF 
> policy on charsets and languages", he should cite BCP17, whereas if he 
> means "the January 1988 version of the IETF policy on charsets and 
> languages" he should cite RFC2277.  in most cases the latter is closer 
> to what is intended, because the author is referencing a particular 
> specification rather than giving a pointer to the current 
> specification.

Good point.

I note in passing that the IPR boilerplate specifically
mentions "BCP 78" and "BCP 79", while the 'Status of this 
Memo' boilerplate instead refers to "RFC 3667" and
"RFC 3668".
From blilly at erols.com  Sat Jan 22 12:34:01 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Jan 22 12:36:29 2005
Subject: [rfc-i] troff/nroff macros for RFCs and I-Ds
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

> [rfc-i] Re: [xml2rfc] request to deprecate numeric citations in xml2rfc
>  Date: 2005-01-12 11:48
>  From: Bill Fenner <[e-mail]>
>  To: [e-mail]
>  CC: [e-mail], [e-mail], [e-mail], [e-mail]
>  
> I have a set of nroff macros that I've been using for a long time
> that require groff and either 2 or 3 passes, but generate a ToC and
> cross-references automatically within nroff.

I have a set of macros that I've been using for a short time,
but they are not groff-specific, and a single pass is all that's
required (I do have some postprocessing scripts to repaginate
so that the TOC emitted at the end is put in the correct
place).  Would the RFC Editor be interested in making a set of
RFC/I-D-specific macros available to authors? [I can put
together an I-D describing use of the macros].
From blilly at erols.com  Sat Jan 22 12:35:07 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Jan 22 12:36:30 2005
Subject: [rfc-i] draft-rfc-editor-rfc2223bis-08.txt
Message-ID: <[e-mail]>

Bob Braden wrote:
> 
> We have just submitted a new Internet Draft that is an update to the
> replacement for RFC 2223, Instructions to RFC Authors.

Regarding PostScript vs. text versions, the draft says:


  3.2  PostScript Format Rules

      (1p) Standard page size is 8 1/2 by 11 inches (216 by 279 mm).

      (2p) Leave a margin of 1 inch (25 mm) on all sides (top, bottom,
           left, and right).

      (3p) Main text should have a point size of no less than 10 points
           with a line spacing of 12 points.

Nroff produces text equivalent to horizontal character width
of 0.1 inch and vertical spacing of 1 Pica (equal to 12 points).
The text lines are therefore 7.2 inches long, and page length
is 58 Picas, or 9 2/3 inches.  The PostScript Format Rules
necessitate different page breaks from text versions, which is
unfortunate.  Line length also differs, which can be a problem
for diagrams, etc.   8.5 inches page width with 1.0 inch left
and right margins leaves a line length of only 6.5 inches. An
11 inch page length with 1.0 inch top and bottom margins leaves
room for 9 inches of text, or 54 lines at 12 point spacing.

Text and PostScript versions could be made identical if the
PostScript Format Rules were revised to use (8.5 - 7.2)/2
or 0.65 inch left and right margins and (11 - 9 2/3)/2 or
2/3 inch top and bottom margins on 8.5 x 11 inch paper.

I believe that there are a number of published RFCs where
the PostScript versions have other than 1.0 inch margins
(e.g. RFC 1168).
From blilly at erols.com  Sun Jan 23 12:01:11 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Jan 23 12:02:06 2005
Subject: [rfc-i] draft-rfc-editor-rfc2223bis-08.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sun January 23 2005 11:58, Keith Moore wrote:

> It would be difficult to have two versions of a document with different 
> typefaces (say, TimesRoman vs. Courier) have both documents look good, 
> and get the page breaks in the same places in each document.

If one objective is to have a PostScript version look
like the text version, ideally one would use a
monospaced font like Courier rather than a proportionally
spaced font like Times Roman [1].

> 12pt  
> spacing is equivalent to 6 lines/in,

Yes, and that's the same as nroff spacing. But the page
length is different; 9.0 inches per the PostScript
format rules vs. 9.6666667 inches for the text version.

> but using 10pt TimesRoman type, to  
> get 72 characters per line you'd need for line lengths to be less than 
> 5in.

For a proportionally spaced font like Times Roman, that
would be highly dependent on the text content; a line
of 'i's and a line of 'W's will have very different
lengths.

> The lines aren't going to break in the same places either because  
> of proportional spacing, which means that text that's at the bottom of 
> page X in one document will be at the top of page X+1 in the next.

Indeed, and the question that I'm raising is whether it's
wise to force that to be the case by requiring the number
of lines of text to be different in text and PostScript
versions.

> And  
> one of the reasons you want to use PostScript is to include figures you 
> can't adequately represent in plain text, which is also going to change 
> page breaks.

Not necessarily; if one uses pic (grap, dformat, etc.)
for simple diagrams and chooses object dimensions
carefully, diagrams can be the same size in text and
PostScript versions.
 
> > Line length also differs, which can be a problem
> > for diagrams, etc.   8.5 inches page width with 1.0 inch left
> > and right margins leaves a line length of only 6.5 inches.
> 
> Which is probably longer than it should be for good readability.

Feel free to argue for reducing the text version line
length below 7.2 inches, as it has been for ages.



1. troff has a mechanism to force a proportionally-spaced
   font to be monospaced, and that is what I did for the
   PS and PDF versions of draft-lilly-text-troff-00. It
   doesn't look great, but line and page breaks are
   consistent (margins, however, do not conform to the
   2233 PostScript format rules.  The next revision of
   that draft will use Courier (as it won't use ms macros).
From blilly at erols.com  Mon Jan 24 11:32:18 2005
From: blilly at erols.com (Bruce Lilly)
Date: Mon Jan 24 11:34:56 2005
Subject: [rfc-i] draft-rfc-editor-rfc2223bis-08.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sun January 23 2005 17:18, Keith Moore wrote:

> >> The lines aren't going to break in the same places either because ?of 
> >> proportional spacing, which means that text that's at the bottom of 
> >> page X in one document will be at the top of page X+1 in the next.
> >
> > Indeed, and the question that I'm raising is whether it's wise to 
> > force that to be the case by requiring the number of lines of text to 
> > be different in text and PostScript versions.
> 
> That is going to be the case anyway, unless you are producing a 
> PostScript version solely to produce a PDF to make it easier for people 
> who use brain-damaged operating systems that can't print plain text 
> properly. ? (those operating systems can't print PostScript either, but 
> these days almost everybody has a PDF viewer).

That isn't the sole reason to produce PostScript (another is for
improved rendition of diagrams), but given the sheer number of
such "people who use brain-damaged operating systems", it's a
valid consideration, and a very good reason to ensure that page
breaks occur consistently with the text version, so that a
reference to RFC 9999 page 17 (e.g. in errata or in comments
in response to a RFC) really does refer to page 37 in both
versions and not page 19 in one version.

I note that the PDF versions that the RFC Editor produces for
just such a purpose do have page breaks consistent with the
text version, and (necessarily) do NOT have the 1.0 inch top
margin that the RFC Editor's PostScript version requires (and
those documents are evidently produced from PostScript, by
the "enscript" program followed by Ghostscript to generate
PDF from PostSCript; at least that's what the information in
the PDF files suggests).

I'm simply suggesting that rather than have rules which the
RFC Editor intentionally violates in order to produce
consistent PDF documents, that the rules be revised to
conform to that practice.  Whether that means balanced
(for 8.5x11 paper) 2/3 inch top and bottom margins or
1.0 inch bottom and 1/3 inch top margins or some other way
of splitting the 1 1/3 inch difference between the 58 line
(@ 1/6 inch = 1 Pica = 12 points per line) text version and
11.0 inch paper height is a detail. [2/3 inch, however, is
very close to the 0.65 inch horizontal margins which would
allow 7.2 inch content on 8.5 inch wide paper]

Alternatively, line spacing in the PostScript version
could be reduced to 11 points, yielding 58 (and a fraction)
lines in 9.0 inches.  But that would screw up diagrams
(details below).

> >> And ?one of the reasons you want to use PostScript is to include 
> >> figures you can't adequately represent in plain text, which is also 
> >> going to change
> >> page breaks.
> >
> > Not necessarily; if one uses pic (grap, dformat, etc.) for simple 
> > diagrams and chooses object dimensions carefully, diagrams can be the 
> > same size in text and PostScript versions.
> 
> That's _way_ too much trouble for a very dubious benefit.

If I want a diagram showing connection between a client
and server, and I'm using troff (or nroff) for document
production, it's much LESS trouble to use pic:
.PS
box "Client" ; line right ; box "Server"
.PE
than to fiddle around with ASCII characters (which
won't render properly in a proportionally spaced
font anyway).  The default height for pic boxes is
1/2 inch, which is exactly 3 lines in nroff and,
well, 1/2 inch in troff.  It is therefore desirable to
have vertical spacing consistent (which the specified
12 point spacing achieves, but a change e.g. to 11
point spacing would destroy).

> >>> Line length also differs, which can be a problem for diagrams, etc. ?
> >>> ?8.5 inches page width with 1.0 inch left and right margins leaves a 
> >>> line length of only 6.5 inches.
> >>
> >> Which is probably longer than it should be for good readability.
> >
> > Feel free to argue for reducing the text version line length below 7.2 
> > inches, as it has been for ages.
> 
> Readability has more to do with the number of characters per line than 
> the actual length of the line. ?6.5in * 15cpi is almost 100 characters 
> versus 72 characters for the text version.

I would have no problem with a restriction on the
number of characters per line in the PostScript version,
so long as it permits at least 72 characters per line.

But to accommodate diagrams, which obviously could be
as wide as 7.2 inches in the text version, I would
prefer to see the left/right margin requirements
relaxed to permit uniform width for diagrams in both
versions (i.e. to permit 7.2 inch width in the
PostScript version), independent of any such restriction
on the number of characters per line.

> If you want to use 10pt  
> type on 8.5in x 11in paper, there's a good argument to be made for 2 
> column text.

RFCs are not formatted for 2 column text.  Again, feel
free to propose such a change if you think it's necessary,
but it would be a major departure from 3 decades of
practice.  It would also pose serious problems for
diagrams in text versions, unless you want to allow
switching back and forth between one- and two-column
text on a page (which introduces additional issues). It
would also be a problem for URLs, which are sometimes
too long to fit in a 72-character line.
From duerst at w3.org  Mon Jan 24 02:17:46 2005
From: duerst at w3.org (Martin Duerst)
Date: Mon Jan 24 17:26:14 2005
Subject: [rfc-i] draft-rfc-editor-rfc2223bis-08.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <6.0.0.20.2.20050124190601.0750a260@localhost>

There are large areas of the world where 8 1/2 by 11 paper is
not available, but A4 paper is easily available.
This leads to two issues:

1) Some Postscript drivers check for paper size in a way that
    makes it impossible to output the resulting Postscript file
    on other paper sizes without hacking the Postscript with
    a text editor. Other Postscript drivers are more tolerant.

    The replacement of RFC 2223 should say that Postscript should
    be produced in such a way as to print even on slightly different
    paper sizes.

At 05:35 05/01/23, Bruce Lilly wrote:

 >Text and PostScript versions could be made identical if the
 >PostScript Format Rules were revised to use (8.5 - 7.2)/2
 >or 0.65 inch left and right margins and (11 - 9 2/3)/2 or
 >2/3 inch top and bottom margins on 8.5 x 11 inch paper.

2) A4 is longer but narrower than 8 1/2 by 11. This raises
    the question whether 7.2 inches will fit on an A4 page.
    7.2 inches is 18.288 cm. The width of an A4 page is
    21 cm. That means 2.712 cm of white space, or 1.356 cm
    on each side, or roughly -0.534 inches. Not very much
    in particular in terms of aestethics, but probably okay
    for most printers.


Regards,    Martin.