home *** CD-ROM | disk | FTP | other *** search
/ The Fred Fish Collection 1.5 / ffcollection-1-5-1992-11.iso / ff_disks / 400-499 / ff473.lzh / CNewsSrc / cnews_src.lzh / notebook / rfcerrata < prev    next >
Text File  |  1990-01-11  |  3KB  |  130 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. says that
  71. .I cancel
  72. control messages should stop propagating if the receiving system
  73. is ``unable to cancel the message as requested''.
  74. It is not clear what this means, given that modern news systems hang
  75. onto cancellations for not-yet-seen articles in hopes of being able
  76. to cancel them in the future.
  77. B 2.11 interprets absence of the target article as ``unable to cancel''.
  78. It would improve the efficacy and reliability of
  79. \fIcancel\fRs
  80. to propagate them anyway, given that feed anomalies are widespread.
  81. There have been verified instances in which cancellations did not achieve
  82. anywhere near the propagation of the original article.
  83. In the interests of robustness,
  84. C News interprets absence of the target article as deferred cancellation
  85. rather than failure to cancel, and propagates the
  86. \fIcancel\fR.
  87. .SH
  88. ihave/sendme not documented
  89. .PP
  90. The description of the ihave/sendme protocol is so vague
  91. as to be useless to an implementor.
  92. See the
  93. C news
  94. documentation for an adequate description of the protocol.
  95. The description in
  96. RFC 1036
  97. also contains an error:
  98. .I remotesys
  99. is not optional;
  100. given that there may be multiple message-ids preceding it,
  101. there would be no way
  102. (other than ad-hocery)
  103. to tell if the final argument were a message-id
  104. or a
  105. .I remotesys .
  106. .SH
  107. Case-sensitivity in message-ids
  108. .PP
  109. RFC 1036 says nothing about whether message-ids are case-sensitive or not,
  110. thereby punting the issue to RFC 822.
  111. The RFC 822 rules are horrendously complex and no news system has ever
  112. implemented them correctly.
  113. (B 2.10 considers them fully case-sensitive, which is wrong.
  114. B 2.11 considers them fully case-insensitive, which is also wrong.
  115. C News gets the normal case right, but correct handling of certain
  116. obscure RFC 822 constructs would
  117. require a complex parsing algorithm; fortunately, the cases where this
  118. matters appear to be extremely rare.)
  119. Simplification appears necessary.
  120. .SH
  121. New headers
  122. .PP
  123. The B news
  124. .B Supersedes:
  125. header needs to be documented in the next revision of the RFC,
  126. as does the C news generalisation,
  127. .B Also-Control:
  128. (see
  129. .I relaynews (8)).
  130.