idnits 2.17.1 draft-rfc-image-files-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC2223, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2223, updated by this document, for RFC5378 checks: 1997-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO19005-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO19005-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO32000-1' ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3778 (Obsoleted by RFC 8118) ** Obsolete normative reference: RFC 5620 (Obsoleted by RFC 6548, RFC 6635) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Braden 3 Internet-Draft USC/ISI 4 Updates: 2223 (if approved) J. Klensin 5 Expires: September 13, 2012 March 12, 2012 7 Images in RFCs 8 draft-rfc-image-files-03 10 Abstract 12 Documents in the RFC series normally use only plain-text ASCII 13 characters and a fixed-width font. However, there is sometimes a 14 need to supplement the ASCII text with images -- e.g., graphics, 15 equations, or pictures. The historic solution to this requirement 16 has allowed secondary PDF and/or Postscript files, but this approach 17 has seldom been used because it is awkward for authors and publisher. 18 This memo sugests a convenient scheme for logically including 19 authoritative diagrams, illustrations, equations, or other graphics 20 within RFCs. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. A New Scheme for Images: Composite RFCs . . . . . . . . . . . 4 58 3. Construction of an Image File . . . . . . . . . . . . . . . . 5 59 4. Requirements for the Base File . . . . . . . . . . . . . . . . 6 60 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Figures Section . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Formatting Changes . . . . . . . . . . . . . . . . . . . . 7 63 5. Submission and Processing of the Image File . . . . . . . . . 8 64 6. Bundled Composites . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Implementation Considerations . . . . . . . . . . . . . . . . 9 66 8. RFC Repository File Formats . . . . . . . . . . . . . . . . . 10 67 9. Internationalization Considerations . . . . . . . . . . . . . 11 68 10. Approval and Authorization . . . . . . . . . . . . . . . . . . 11 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 14.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 76 A.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Published documents in the RFC series normally use only plain-text 82 ASCII characters and a fixed-width font [RFC2223]. This simple 83 convention has the advantage of a stable encoding for which a great 84 variety of tools are readily available for viewing, searching, 85 editing, etc. 87 Inclusion of diagrams, state machines, complex equations, and other 88 graphics in RFC text has generally relied on the imaginative use of 89 ASCII characters ("ASCII artwork"). However, in a few cases over the 90 years, ASCII artwork has been inadequate for images needed or desired 91 in RFCs. The solution to this dilemma has been to allow multiple 92 versions of an RFC: a primary ASCII version as well as secondary 93 versions that are encoded using PDF and Postcript. The PDF and 94 Postscript versions are "complete", containing a copy of the text as 95 well as the full images [RFC2223]. The textual content and layout of 96 the PDF/PS version is required to match the base version as closely 97 as possible. However, except in a few rare exception cases (see, 98 e.g., [RFC1129]) the ASCII text version is considered the official 99 expression of the RFC, and it is always normative for standards-track 100 documents. We will refer to this scheme as "txt/ps/pdf" 101 representation. 103 The three versions of an RFC using the txt/ps/pdf representation are 104 in separate files in the primary RFC repository 105 (http://www.rfc-editor.org/rfc/), with suffixes ".txt", ".pdf", and 106 ".ps". The RFC Editor search engine returns links to all three 107 versions when they are present in the repository. 109 Unfortunately, the txt/ps/pdf approach has been awkward for both 110 editor and author, and it is error-prone. Therefore, it has seldom 111 been used (roughly 50 out of 5000+ RFCs). The problem is that, in 112 general, only the author has the tools to edit the PDF and Postscript 113 versions. The RFC Editor can readily edit only the primary ASCII 114 text, and then the author must incorporate the resulting changes into 115 the PDF/PS version while maintaining the "look" of the RFC to the 116 extent possible. There is no practical way for the RFC Editor to 117 verify that this is done correctly, which may lead to editorial 118 errors, reader confusion. It may also lengthen publication time. 120 This memo suggests a much better scheme for including figures, 121 illustrations, and graphics to an RFC. We hope that the method 122 proposed here will solve the image problem for RFC publication, while 123 preserving the convenience, stability, and searchability of ASCII 124 base documents. The txt/ps/pdf approach would still be possible (and 125 in any case, RFCs using the historic scheme will continue to exist in 126 the RFC repository forever). 128 Discussion of this document is being moved to the rfc-interest 129 mailing list. For subscription information and archives, see 130 http://www.rfc-editor.org/mailman/listinfo/rfc-interest. 132 2. A New Scheme for Images: Composite RFCs 134 Under the suggested scheme, an RFC would be either a single ASCII 135 file as generally used today, or a composite of two files: an ASCII- 136 only "base file" containing the text of the RFC, and an "image file". 137 When present, the image file would be a PDF file that contained only 138 images, captions, and title information. Neither file of the 139 composite would be complete without the other, and a reference to the 140 RFC would be considered a reference to both files. An RFC would then 141 be a logical entity whose complete representation could require two 142 files, base and image. 144 The base file would be formatted exactly like current ASCII RFCs, 145 with minor exceptions described below. An image file would contain 146 one or more items that will be known collectively as "figures", 147 whether they are actually diagrams, pictures, tables, equations, 148 artwork, or other non-textual constructions. 150 If the approach of this document is adopted, terms like "the RFC" 151 will refer to the combination of the base RFC file and an image file 152 if the latter is supplied. Note that, just as with the txt/ps/pdf 153 representations, an RFC is a logical entity whose complete 154 representation requires multiple files. In particular, the IPR 155 statement in the base file ("Rights Contributors Provide to the IETF 156 Trust in Contributions BCP 78, RFC 5378 [RFC5378]) would apply to the 157 composite, including the image file if one is present. 159 An ASCII RFC traditionally uses a file name in the form of 160 "rfcN.txt", where N is integer RFC number without leading zeros. The 161 image file that is associated with RFC number N could be named 162 "rfcN.img.pdf". As noted earlier, the repository contains RFCs with 163 file names "rfcN.ps" and "rfcN.pdf", using the historic txt/ps/pdf 164 representations. 166 This "image file" scheme was inspired by a tradition of book 167 publishing, in which pictures, figures, or "plates" may be grouped 168 together following the text ("end figures"), or even bound separately 169 from the main body of the text. 171 In principle, we could allow an image file to be encoded using both 172 PDF and Postscript, since mechanical translation is possible in both 173 directions. However, in the 20 years since the adoption of the txt/ 174 ps/pdf representations, the PDF format has become a de facto standard 175 for electronic documents, and readers for it are universally 176 available. Furthermore, PDF has been standardized as a format for 177 document archiving, as discussed further in the next section. 178 Therefore, we propose to allow only PDF for image files, simplifying 179 the new approach by not including a Postscript file option. 181 3. Construction of an Image File 183 An image file would be a single PDF file, consistent with the 184 description in [RFC3778] and defined in [ISO32000-1]. The particular 185 PDF form must be version-stable and must not contain any external 186 references in scripts or otherwise. Those requirements are satisfied 187 by the PDF/A [ISO19005-1] [ISO19005-2] profile. The RFC Editor may 188 authorize other variants of PDF in the future. 190 There is an issue of whether particular PDF generators PDF that claim 191 to satisfy PDF/A actually do so. Future experience may require 192 published guidelines on PDF-generating software that claims to 193 satisfy PDF/A but does not. 195 Except as otherwise specified in this document, an image file should 196 contain only figures, supporting labels and captions, headers, and 197 footers. It should not contain explanatory text or other materials 198 that could reasonably be expressed in plain-text form in the base 199 file. In particular, required sections of RFCs, such as IANA 200 Considerations or references, must be completely understandable from 201 the base text file. Any figures referenced from those sections may 202 contain only supplemental material. 204 The image file would be paginated using the same 8.5 x 11" format as 205 the base document, and the image file pages would be consecutively 206 numbered. The first page number of the image file would follow the 207 last page number of the base RFC. Each page of the image file would 208 contain the same headers and footers as the base file, except for one 209 change in the footer, suggested below. Since editing the base file 210 may change its pagination, it may be simplest to ask the RFC Editor 211 to overlay the headers and footers onto the image file near the 212 completion of editing. Each page would need blank space at the top 213 and bottom for this purpose. The amount of blank space is to be 214 determined, but 0.5" might be a reasonable value. 216 Figures included in the image file would have to be labeled in a 217 fashion that facilitated referencing from the base RFC. The labels 218 should normally be numeric and monotonic. Simple consecutive 219 integers will usually be the best choice, but in some cases it might 220 be desirable to use a hierarchical scheme like:
.. 221 An author who believes that another labeling scheme would increase 222 clarity should consult the RFC Editor. 224 4. Requirements for the Base File 226 4.1. Overview 228 A base file would be unchanged by the presence of an image file, 229 except for the following. 231 o The page number of the end-of-RFC boilerplate page would be 232 changed to be logically one page after the last image file page. 234 o A new unnumbered "Figures" section would be required. This is 235 described below. 237 o For a composite RFC, a minor modification to the first-page header 238 of the base file and to the footers of both base and image files 239 would tie the two files together. This is described below. 241 4.2. Figures Section 243 An RFC that used this scheme (and had any figures) would need to 244 include a Figures section in the ASCII base file. The Figures 245 section should immediately follow the Table of Contents, if any, and 246 precede the body of the document. The Figures section should list 247 all figures in tabular form, indicating for each one the figure 248 identification, title, and page number(s). 250 The style for the Figures section has not yet been fully specified. 251 Here is a suggested example. 253 ___________________________________________________________________________ 254 Table of Contents 256 1. Introduction .................................................... 1 257 2. Philosophy ...................................................... 7 258 2.1 Elements of the Internetwork System ........................ 7 259 2.2 Model of Operation ......................................... 8 260 2.3 The Host Environment ....................................... 8 261 (etc) 263 Figures 265 Figure 1: Protocol Layering ....................................... 2 266 Figure 2: Protocol Relationships .................................. 9 267 Figure 3: TCP Header Format .................................. 15, *86 268 Figure 4: Send Sequence Space ..................................... 20 269 Figure 5: Receive Sequence Space .................................. 20 270 Figure 6: TCP Connection State Diagram ....................... 23, *87 271 Figure 7: Basic 3-Way Handshake for Connection Synchronization 31, *88 272 (etc) 274 *Page in Image file 276 (Page 1 follows) 277 ___________________________________________________________________________ 279 An RFC that includes a base file may include ASCII artwork that is 280 suggestive of a figure in the image file, but there is no requirement 281 to do so. When such an approximate figure appears as ASCII artwork 282 in the base file, its figure identification and caption must match 283 those of the corresponding figure in the image file, and the entry in 284 the Figures table should specify the page numbers in both the base 285 and image file. In the example shown above, image file page numbers 286 are marked with an asterisk. Note that very simple ASCII artwork 287 need not have corresponding material in the image file. 289 Groups of mathematical equations form one particular case in which it 290 may be desirable for a base file to include ASCII artwork 291 approximations. This will ease searching for such documents using 292 equation terminology. equations. There are well-established 293 conventions for approximating fairly complex equations using ASCII 294 artwork. 296 4.3. Formatting Changes 298 It would be necessary to tie the base and image files together, to 299 make clear they are part of one RFC. Here is an initial suggestion 300 for formatting. 302 The header line "Request for Comments: nnnn" in the base file 303 could be changed to "Request for Comments: nnnn/Base". For 304 consistency, the lefthand footer could become "RFC nnnn/Base". 305 The lefthand footer in the image file could then be: "RFC nnnn/ 306 Image". 308 The following sentence could be placed in the "Status of this 309 Memo" section: "This RFC is a composite of this base file and PDF 310 image file ." 312 5. Submission and Processing of the Image File 314 If an image file is needed, it should be submitted as an .img.pdf 315 file along with the ASCII text file. 317 The image file could be submitted without headers or footers. The 318 RFC Editor could then overlay the image file with the appropriate 319 headers and footers, with correct pagination. The RFC Editor would 320 do no editing of the image file beyond adding headers and paginated 321 footers. If editing the base file revealed problems with figures in 322 the image file, the authors would be asked to create a new image 323 file. 325 6. Bundled Composites 327 The base/image file split should be very convenient for the process 328 of editing and publishing RFCs, and all tools that return RFC meta- 329 data should alert the reader to the composite structure. However, 330 users may sometimes prefer to obtain an existing composite RFC as a 331 single file in a bundled format. 333 Our suggestion for such bundling is to again use PDF encoding. Thus, 334 corresponding to the composite file pair (rfcN.txt, rfcN.img.pdf), 335 there would be a new file with a name like "rfcN.bun.pdf". The 336 .bun.pdf file would be a single PDF file containing a facsimile of 337 the .txt file (like the current .txt.pdf files) followed by the image 338 file. 340 It is important to understand what is being suggested here. The 341 .bun.pdf files would never be submitted for publication by authors; 342 instead, the RFC Editor would mechanically generate the .bun.pdf 343 files upon publication of the .txt and .img.pdf files (just as 344 .txt.pdf files are now generated automatically). Some users might 345 choose to consider the bundled .bun.pdf file as "the RFC", but the 346 RFC Editor would consider "the RFC" to be the {.txt, .img.pdf) file 347 pair. We note that: 349 The composite is logically a single RFC that can be normative for 350 a standards-track document. 352 The .bun.pdf bundle, whch would be mechanically derived from the 353 composite pair, might reasonably be declared in the future to be 354 equally normative. 356 The continued existence of a base file that is readily editable by 357 the RFC Editor and readily searchable by users would maintain the 358 advantages of the present ASCII-based scheme. We are not 359 suggesting that, at least in the near term, the composite 360 structure with its ASCII text component be abandoned. 362 On the other hand, the .bun.pdf bundle could be a transitional 363 step towards a future world where RFCs are published in pure .pdf. 365 7. Implementation Considerations 367 Implementation of the image file scheme has a number of implications. 369 1. The Internet Draft repository must allow submission and retrieval 370 of both base and (when present) image files. 372 2. Internet Draft file names could be draft-...-vv.txt and 373 (optionally) draft-...-vv.img.pdf, where "vv" is the normal 374 version number. Updating either file of the composite RFC should 375 increase the version numbers "vv" in both files. We DO NOT want 376 two separate version numbers for one I-D. 378 3. The RFC Editor would need to be able to overlay headers, footers, 379 and page numbers on a given image file. It is claimed that at 380 least Adobe Acrobat Professional includes this capability, and 381 that it also has limited editing capability. 383 4. The RFC Editor would also need a tool to verify that a given 384 image file satisfies the constraints of PDF/A and that the 385 original image can be overlaid with headers and footers. 387 5. Some RFC Editor scripts and tools would need extensions. 389 6. Small extensions to xml2rfc [RFC2629] would be useful to create 390 base/image file cross-references in header and footers, and to 391 build a Figure section. 393 8. RFC Repository File Formats 395 A frequent reaction to the suggestion given in this memo is some 396 confusion over the different file formats that appear in the RFC 397 repository. Here is a brief summary. 399 If a PDF image file exists along with a base ASCII RFC, then RFCs in 400 any format other than that combination (e.g., complete PDF files, 401 HTML, or Postscript) remain supplemental, with the reader taking 402 responsibility for assuring that they are equivalent to the base RFC 403 and image file. That arrangement is identical to the relationship 404 between traditional all-ASCII RFCs and supplemental forms: the RFC 405 Editor has never taken responsibility for guaranteeing that the two 406 are identical in content. 408 The existing .txt.pdf files are not affected by this proposal, nor 409 are any of the traditional non-ASCII formats. The .txt.pdf files are 410 facsimiles of .txt (base files) in PDF, introduced to help Windows 411 users read RFCs online. However, Microsoft has more recently 412 provided an elementary ASCII editor, which probably makes the 413 .txt.pdf files unnecessary in any case. 415 In summary: 417 o rfcN.txt: ASCII-only file. In the traditional system, complete 418 normative file. In the new system, text (base) part of normative 419 composite RFC, or stand-alone normative text file when no image 420 file is necessary. 422 o rfcN.ps: Traditional system -- a Postscript file that includes 423 figures and whose text is intended to be the same as the normative 424 .txt file, but is generally non-normative itself. No new rfcN.ps 425 files would be created after adoption of the image file proposal. 427 o rfcN.pdf: Traditional system -- a PDF file that includes figures 428 and whose text is intended to be the same as the normative .txt 429 file, but is generally non-nformative itself. 431 o rfcN.txt.pdf: Traditional system: Facsimile of corresponding .txt 432 file. 434 o rfcN.img.pdf: New system: image file component of a composite RFC. 436 o rfcN.bun.pdf: New system: bundled composite file. 438 9. Internationalization Considerations 440 Our scheme of image files does not, and is not intended to, support 441 character set internationalization for RFCs. It does not allow an 442 author to omit the ASCII text from the base file and instead include 443 the entire RFC text as one (very large) image file. 445 However, we should note two examples that illustrate special cases. 447 1. RFC 3743 [RFC3743] on internationalized domain names for Chinese, 448 Japanese, and Korean contains a number of examples that may be 449 hard to follow because they can represent those characters only 450 in "U+nnnn" form. An image file could be used that would show 451 the alternative Chinese characters for the examples. This would 452 not diminish either the ability to search the base text or index 453 the document or its readability for those of us for whom reading 454 Chinese characters is difficult, but it should help those who can 455 read them. 457 2. Suppose that a proposed RFC contained a section derived from 458 Japanese text. The author might put an English translation into 459 that section of the base document, note that the original was 460 really in Japanese, and attach the Japanese as an appendix in an 461 image file. This should raise no difficulties for informative 462 documents. For normative documents, however, the existence of 463 the Japanese original would raise some issues about what was 464 actually authoritative, which is very undesirable. 466 [Note in Draft: A separate proposal [Hoffman-RFC-UTF8] is under 467 consideration to permit UTF-8 strings to appear directly in text RFCs 468 under restricted circumstances.] 470 10. Approval and Authorization 472 Placeholder: In its capacity as the body that approves the general 473 policy followed by the RFC Editor [RFC2850], [RFC5620]), the RSOC or 474 full IAB would eventually need to review and sign off on this 475 proposal after its tentative approval by the RFC Series Editor (RSE). 477 11. Security Considerations 479 This specification addresses documentation standards and adding 480 additional flexibility to them. It does not, in general, raise any 481 security issues. However, unless the specifications of this document 482 are carefully followed, the image format recommended, PDF, may 483 potentially contain external references or scripts that could 484 introduce security problems. That problem could be largely or 485 completely alleviated, and long-term stability improved, by exclusive 486 use of the PDF/A format as discussed in Section 3. The RFC Editor 487 and other publishers should exercise due care to ensure that no such 488 references or scripts appear in the archives. 490 12. IANA Considerations 492 This document requires no actions by the IANA. An intentional 493 consequence of the model is that IANA will not need to inspect the 494 image file in order to carry out its task of evaluating proposed RFCs 495 for potential actions. 497 13. Acknowledgments 499 The impetus for this specification arose during a discussion during 500 an RFC Editorial Board meeting after one of the IETF's many 501 discussions about "modern" formats for RFCs. Aaron Falk made several 502 specific suggestions that have been reflected in the document. The 503 RFC Editor staff and other Editorial Board members contributed 504 suggestions without which this version would not have been possible, 505 as did Steve Bellovin, Alfred Hoenes, Olaf Kolkman, and Henrik 506 Levkowetz. 508 14. References 510 14.1. Normative References 512 [ISO19005-1] 513 International Organization for Standardization (ISO), 514 "Document management -- Electronic document file format 515 for long-term preservation -- Part 1: Use of PDF 1.4 516 (PDF/A-1)", ISO 19005-1:2005, 2005. 518 [ISO19005-2] 519 International Organization for Standardization (ISO), 520 "Document management -- Electronic document file format 521 for long-term preservation -- Part 2: Use of ISO 32000-1 522 (PDF/A-2)", ISO 19005-2:2011, 2011. 524 [ISO32000-1] 525 International Organization for Standardization (ISO), 526 "Document management -- Portable document format -- Part 527 1: PDF 1.7", ISO 32000-1:2008, 2008. 529 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 530 RFC 2223, October 1997. 532 [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The 533 application/pdf Media Type", RFC 3778, May 2004. 535 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 536 to the IETF Trust", BCP 78, RFC 5378, November 2008. 538 [RFC5620] Kolkman, O. and IAB, "RFC Editor Model (Version 1)", 539 RFC 5620, August 2009. 541 14.2. Informative References 543 [Hoffman-RFC-UTF8] 544 Hoffman, P. and T. Bray, "Using non-ASCII Characters in 545 RFCs", November 2008, . 548 [RFC1129] Mills, D., "Internet Time Synchronization: The Network 549 Time Protocol", RFC 1129, October 1989. 551 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 552 June 1999. 554 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of 555 the Internet Architecture Board (IAB)", BCP 39, RFC 2850, 556 May 2000. 558 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 559 Engineering Team (JET) Guidelines for Internationalized 560 Domain Names (IDN) Registration and Administration for 561 Chinese, Japanese, and Korean", RFC 3743, April 2004. 563 Appendix A. Change Log 565 A.1. Version -03 567 Conversations about the formats of RFCs are restarting at IETF 83 in 568 March 2012. This version of this draft is a minor update of the 569 November 2008 version -02 to enter it into that discussion. It 570 reflects changes in ISO standards and the RFC Editor model since 2008 571 as well as a few minor editorial corrections. 573 Authors' Addresses 575 Robert Braden 576 USC/ISI 577 4676 Admiralty Way 578 Marina del Rey, CA 90292 579 USA 581 Phone: +1 310 448 9173 582 Email: braden@isi.edu 584 John C Klensin 585 1770 Massachusetts Ave, #322 586 Cambridge, MA 02140 587 USA 589 Phone: +1 617 491 5735 590 Email: john-ietf@jck.com