Subject: [edu-team] RFC Editor Tutorial and Q&A

From: Alice Hagens <[email-masked]>
Date: Tue, 24 Apr 2007 18:08:50 -0700

EDU Team,

FYI, here are a few notes about the current RFC Editor tutorial and  
the kinds of questions we get.

The primary updates between IETF 67 and 68 were:
  a. more about IANA Considerations by Michelle from IANA
  b. details of publication process from authors' perspective

Below is the Q&A summary that followed the RFC Editor Tutorial in  
Prague.  Afterwards, we emailed a link to the slides and this Q&A  
summary to the attendees who signed in.

Your comments and corrections are welcome.

Alice
for the RFC Editor

-----------------------------------------------------
// Q&A at the RFC Editor Tutorial
// IETF 68 - March 18, 2007

Q1 (to IANA): What's the deal with IANA assigning numbers requested
in a draft before it is published as an RFC? For example, when it
would be better to do the testing with the actual number.

A (Michelle): Early allocation does happen sometimes. We prefer to go
through the normal channels as much as possible, but there are
specific times when the numbers are needed early. See RFC 4020,
"Early IANA Allocation of Standards Track Code Points".  In general,
please use "TBD1", "TBD2", etc., in your draft when referring to
numbers that have not yet been assigned by IANA. This avoids the
problem of an exact number being used throughout the draft, and in
implementations, and then causing problems when that number is
assigned for another purpose.
-----------------------------------------------------

Q2: What is the official naming convention? For example, RFC 0059 or
RFC 59?  What are you going to do after RFC 9999?

A:  The official document ID is "RFC 59", but since "59" IS a number,
it can be written "059", "0059", "00059", etc.  It is not a 4-digit
identifier, it is a positive integer identifier.  Since it is just a
number, in fact, leading zeros in the RFC number must be irrelevant.
When we make file names there are no leading zeroes; it is "RFC59".
That was a programming decision that Jon Postel made 20 years ago.

The RFC after 9999 will have ID "RFC 10000". This will force a kind
of millennium update for RFC Editor software and some IETF software.
------------------------------------------------------

Q3: Why are there differences between the I-D formatting requirements
and the RFC formatting requirements?  It would be helpful if these
were brought in line.

A: For the most part, we consider general formatting our job and we
have different requirements than Internet-Drafts.  The boilerplate
is different because of procedural/legal matters, and formatting
varies because I-Ds are allowed liberties that we try to avoid in RFCs
(e.g., single spaces that follow a terminating period between
sentences or the presence of a terminology section before the
introduction).

-------------------------------------------------------

Q4: How should citation tags (i.e., symbolic reference tags) be chosen?

A: For RFCs and other numbered specifications, the reference tags are
usually [RFCXXXX], [IEEE-XXXX], [ANSI-XXXX], etc.  As for Internet-
Drafts or other documents, it's your choice.  Commonly, it is
something representative of the title, but not the whole draftstring
(because draftstrings are temporary identifiers that do not appear in
RFCs).  For example, draft-ietf-mpls-rsvp-te-p2mp, "Extensions to
RSVP-TE for Point-to-Multipoint TE LSPs", could have the reference
tag [P2MP-RSVP].  A common convention in academic publishing is to
use the last name of the author and the year of publication -- for
example, [AGGARWAL07].

Note: If you use xml2rfc, the PI <?rfc symrefs="yes"> causes the
symbolic reference tags to be used instead of numeric (i.e., [1]).
We recommend using the citation libraries for RFCs, I-Ds, W3C, JSF,
3GPP, and miscellaneous that are available from http://
xml.resource.org.  They will automatically create reference tags such
as:
[RFC2119], [W3C.REC-xml-names-19990114], [3GPP.25.463],
  and [I-D.ietf-mpls-rsvp-te-p2mp] (for I-Ds, the RFC Editor will
change the tag so that is does not use the full draftstring).
-------------------------------------------------------

Q5: Can xml2rfc be made to put 2 spaces after periods or to wrap the
text at the 72-character line limit?

A: It already does both of those. The xml2rfc output will have 2
spaces after every period (except initials) and wrap the lines at 72
characters.  No matter if you put 1, 2, 3, or 999 spaces between your
sentences in your XML source file, xml2rfc will put 2 spaces after
each period between sentences that are inside <t></t> tags. However,
in artwork/figure elements, because the text is *as it appears* in
your XML source file, it is possible to create text that will not
have 2 spaces after each period.  If you have the PI <?rfc
strict="yes"?>, then xml2rfc will give an error if any of the lines
are over 72 characters.
-------------------------------------------------------

Q6: If I send a text file, will you create an xml source file?

A: No, we will create an nroff source file from the text file of the
approved Internet Draft. Maybe someday a txt -> XML tool will exist,
but not yet.
-------------------------------------------------------

Q7: Can you check my draft to see if the formatting is correct?

A: There is an online IDnits checker made by the IETF Tools Team that
checks your draft and tells you what changes are needed so that it
will be accepted when submitted to [email-masked]. The
IDnits checker is here: http://tools.ietf.org/tools/idnits/
-------------------------------------------------------

_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team