home *** CD-ROM | disk | FTP | other *** search
/ The Fred Fish Collection 1.5 / ffcollection-1-5-1992-11.iso / ff_disks / 300-399 / ff319.lzh / CNewsSrc / cnews.orig.lzh / notebook / rfcerrata < prev    next >
Text File  |  1989-06-27  |  2KB  |  96 lines
  1. .TL
  2. Errors in RFC 1036
  3. .AU
  4. Geoff Collyer
  5. .AI
  6. Department of Statistics
  7. University of Toronto
  8. .SH
  9. Introduction
  10. .PP
  11. RFC 1036,
  12. the standard
  13. .I "du jour"
  14. for the format of Usenet (netnews) messages
  15. contains significant errors,
  16. enumerated below.
  17. References are made to
  18. RFC 850,
  19. the previous netnews message format standard.
  20. .SH
  21. Header order insignificant
  22. .PP
  23. Between
  24. RFC 850
  25. and
  26. RFC 1036,
  27. a sentence stating that the order of message headers is insignificant
  28. has fallen out of the standard.
  29. This may be a reflection of the reality that
  30. B 2.10
  31. news did indeed care about the order
  32. of
  33. .B From:
  34. and
  35. .B Path: .
  36. .SH
  37. ``Re:'' is only three characters
  38. .PP
  39. One sees the contradiction
  40. ``the four characters "Re:"''
  41. repeatedly;
  42. there should be a space after the colon.
  43. .SH
  44. cmsg incorrectly described
  45. .PP
  46. Similary,
  47. RFC 1036
  48. claims that a
  49. .B Subject:
  50. prefix of
  51. ``cmsg''
  52. will be interpreted as denoting a control message;
  53. the correct prefix is
  54. ``cmsg\ ''
  55. (including a space).
  56. .SH
  57. Xref is transmitted
  58. .PP
  59. RFC 1036
  60. says that
  61. .B Xref:
  62. headers should not be transmitted,
  63. yet they are stored on disk as part of message headers,
  64. so they will be transmitted by both B and C news.
  65. The standard appears to be too strict.
  66. .SH
  67. cancels should propagate always
  68. .PP
  69. RFC 1036
  70. claims that
  71. .I cancel
  72. control messages should stop propagating when their target messages
  73. are not present;
  74. it would improve the efficacy of
  75. .I cancel s
  76. to propagate them anyway.
  77. .SH
  78. ihave/sendme not documented
  79. .PP
  80. The description of the ihave/sendme protocol is so vague
  81. as to be useless to an implementor.
  82. See the
  83. C news
  84. documentation for an adequate description of the protocol.
  85. The description in
  86. RFC 1036
  87. also contains an error:
  88. .I remotesys
  89. is not optional;
  90. given that there may be multiple message-ids preceding it,
  91. there would be no way
  92. (other than ad-hocery)
  93. to tell if the final argument were a message-id
  94. or a
  95. .I remotesys .
  96.