home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / N / CNEWS / _CNEWS.TAR / usr / doc / cnews / docs / rfcerrata < prev    next >
Encoding:
Text File  |  1994-09-02  |  8.1 KB  |  292 lines
  1. .Ch "Errors in RFC 1036"
  2. .Ix "RFC 1036" errors
  3. .SH
  4. Introduction
  5. .PP
  6. RFC 1036,
  7. the standard
  8. .I "du jour"
  9. for the format of Usenet (netnews) messages
  10. contains significant errors,
  11. enumerated below.
  12. References are made to
  13. RFC 850,
  14. .Ix "RFC 850"
  15. the previous netnews message format standard,
  16. and also to RFC 822,
  17. .Ix "RFC 822"
  18. the mail message format standard
  19. (which, note, has been slightly amended by RFC 1123).
  20. .Ix "RFC 1123"
  21. .SH
  22. Header order insignificant
  23. .Ix "header order"
  24. .PP
  25. Between
  26. RFC 850
  27. and
  28. RFC 1036,
  29. a sentence stating that the order of message headers is insignificant
  30. has fallen out of the standard.
  31. This may be a reflection of the reality that
  32. B 2.10
  33. news did indeed care about the order
  34. of
  35. .B From:
  36. and
  37. .B Path: .
  38. .SH
  39. .Ix "Re: "
  40. ``Re:'' is only three characters
  41. .PP
  42. One sees the contradiction
  43. ``the four characters "Re:"''
  44. repeatedly;
  45. there should be a space after the colon.
  46. .SH
  47. .Ix cmsg
  48. cmsg incorrectly described
  49. .PP
  50. Similary,
  51. RFC 1036
  52. claims that a
  53. .B Subject:
  54. prefix of
  55. ``cmsg''
  56. will be interpreted as denoting a control message;
  57. the correct prefix is
  58. ``cmsg\ ''
  59. (including a space).
  60. .SH
  61. Xref is transmitted
  62. .Ix Xref:
  63. .PP
  64. RFC 1036
  65. says that
  66. .B Xref:
  67. headers should not be transmitted,
  68. yet they are stored on disk as part of message headers,
  69. so they will be transmitted by both B and C news.
  70. The standard appears to be too strict.
  71. .SH
  72. .Ix "cancel propagation"
  73. .Ix "control messages" cancel
  74. cancels should propagate always
  75. .PP
  76. RFC 1036
  77. says that
  78. .I cancel
  79. control messages should stop propagating if the receiving system
  80. is ``unable to cancel the message as requested''.
  81. It is not clear what this means,
  82. given that modern news systems hang
  83. onto cancellations for not-yet-seen articles in hopes of being able
  84. to cancel them in the future.
  85. B 2.11 interprets absence of the target article as ``unable to cancel''.
  86. It would improve the efficacy and reliability of
  87. \fIcancel\fRs
  88. to propagate them anyway,
  89. given that feed anomalies are widespread.
  90. There have been verified instances in which cancellations did not achieve
  91. anywhere near the propagation of the original article.
  92. In the interests of robustness,
  93. C News interprets absence of the target article as deferred cancellation
  94. rather than failure to cancel,
  95. and propagates the
  96. \fIcancel\fR.
  97. .SH
  98. .Ix "cancel validation"
  99. .Ix "control messages" cancel
  100. cancel validation
  101. .PP
  102. RFC 1036 requires that a
  103. .I cancel
  104. message have a
  105. .B Sender:
  106. or
  107. .B From:
  108. header matching the message it is cancelling.
  109. It is not entirely clear from the text whether this restriction is supposed
  110. to be enforced at the originating site or at each receiving site,
  111. although the latter is implied.
  112. .PP
  113. More seriously,
  114. it is not clear what ``matching'' means in this context,
  115. considering
  116. that a substantial fraction of the information in such lines is typically
  117. in RFC 822 comments.
  118. There is an unfortunate tradition of news readers generating
  119. header comments in varying ways.
  120. There is also a lot of obsolete or misdesigned
  121. news software still operational,
  122. and some of it gratuitously
  123. alters the header comments
  124. (and sometimes even the non-comment parts of the headers!)
  125. in messages passing through.
  126. While theoretically these complications should affect the original and
  127. the cancellation identically,
  128. in practice this is not consistently so,
  129. and it is difficult to generate a cancellation that works dependably.
  130. This is not just speculation;
  131. there are verified cases of the originators
  132. of messages having considerable difficulty cancelling them when it was
  133. important to do so.
  134. .PP
  135. The value of RFC 1036 authentication is also somewhat questionable.
  136. It provides no useful security against malice,
  137. because news is so easy to forge.
  138. While there is some value in preventing accidents,
  139. there is room for
  140. doubt as to whether this is worth
  141. the interference with legitimate cancellations.
  142. .PP
  143. C News
  144. takes the position that the RFC 1036 approach to authentication is
  145. impossible to implement in a practical way,
  146. due to its vagueness and the
  147. prevalence of gratuitous and unpredictable header rewriting,
  148. and on balance the inability to cancel is worse than the largely-illusory
  149. security provided.
  150. C News
  151. therefore does not authenticate cancellations.
  152. .PP
  153. Doing something about the problem is difficult.
  154. Specification of a
  155. .I precise
  156. algorithm for header matching would help,
  157. but finding one that
  158. will disregard gratuitous header mangling is hard.
  159. A more appealing approach would be to authenticate cancellations
  160. by cryptographic means,
  161. .Ix authentication
  162. .Ix cryptography
  163. but there are severe difficulties in key distribution
  164. on an unreliable non-real-time network like Usenet,
  165. and
  166. the cost of checking cryptographic credentials is disturbingly high.
  167. Ultimately,
  168. it may be necessary to abandon destructive control messages
  169. entirely,
  170. or reserve them for rare emergencies and route them through a
  171. trusted moderator for cryptographic authentication.
  172. .SH
  173. ihave/sendme not documented
  174. .Ix ihave/sendme
  175. .PP
  176. The description of the ihave/sendme protocol is so vague
  177. as to be useless to an implementor.
  178. See the
  179. C news
  180. documentation for an adequate description of the protocol.
  181. The description in
  182. RFC 1036
  183. also contains an error:
  184. .I remotesys
  185. is not optional;
  186. given that there may be multiple message-ids preceding it,
  187. there would be no way
  188. (other than ad-hocery)
  189. to tell if the final argument were a message-id
  190. or a
  191. .I remotesys .
  192. .SH
  193. Case-sensitivity in message-ids
  194. .Ix Message-IDs
  195. .PP
  196. RFC 1036 says nothing about whether message-ids are case-sensitive or not,
  197. thereby punting the issue to RFC 822.
  198. The RFC 822 rules are horrendously complex and no news system has ever
  199. implemented them correctly.
  200. (B 2.10
  201. considers them fully case-sensitive,
  202. which is wrong.
  203. B 2.11
  204. considers them fully case-insensitive,
  205. which is also wrong.
  206. C News
  207. gets the normal case right,
  208. but correct handling of certain
  209. obscure RFC 822 constructs would
  210. require a complex parsing algorithm;
  211. fortunately,
  212. the cases where this
  213. matters appear to be extremely rare.)
  214. Simplification appears necessary.
  215. .SH
  216. New headers
  217. .PP
  218. The B news
  219. .B Supersedes:
  220. .Ix Supersedes:
  221. header needs to be documented in the next revision of the RFC,
  222. as does the C news generalisation,
  223. .B Also-Control:
  224. .Ix Also-Control:
  225. (see
  226. .I relaynews (8)).
  227. .SH
  228. ``Keywords''
  229. .Ix keywords header
  230. .Ix "header keywords"
  231. .PP
  232. Section 2 says that a header begins with a ``keyword'' as the header name.
  233. RFC 1036 never defines what a keyword is,
  234. and RFC 822 does not use the term.
  235. ``Keyword'' here must be considered an informal term with no precise meaning,
  236. imposing no additional restrictions on header syntax.
  237. .PP
  238. In particular,
  239. things like ``>from:\ foo@bar'',
  240. which causes B News to choke,
  241. appear to be legal RFC 822
  242. (and hence 1036) headers.
  243. (Before quoting lexical rules,
  244. such as the requirement for balancing brackets,
  245. please
  246. note that the 822 lexical rules are context-sensitive.)
  247. .PP
  248. Theoretical legality notwithstanding,
  249. such bizarre header names are dubious and unwise practice.
  250. RFC 1036 probably should be tightened up to exclude them.
  251. .SH
  252. RFC 822 Comments
  253. .Ix "RFC 822" comments
  254. .PP
  255. RFC 1036 section 2 implies,
  256. both in its general discussion and in its
  257. discussion of the ``From:'' header,
  258. that RFC 822 comments are not,
  259. in general,
  260. accepted in RFC 1036 article format.
  261. However,
  262. the point is not made loudly and explicitly,
  263. and some nit-pickers
  264. argue that RFC 1036 permits dubious practices like timezone name comments
  265. in ``Date:'' headers.
  266. This needs to be nailed down in black and white.
  267. C News
  268. takes a strict position on this in cases where it cares about
  269. the contents of headers.
  270. .SH
  271. Duplicate Headers
  272. .Ix header duplicates
  273. .Ix "duplicate headers"
  274. .PP
  275. RFC 822 requires that at most one ``Date:''
  276. header occur in a message,
  277. and likewise for ``From:'',
  278. although careful reading is needed to discover this.
  279. It permits more than one ``Message-ID:'' or ``Subject:'' header,
  280. and is (of course)
  281. completely silent about ``Newsgroups:'' and ``Path:''.
  282. With the arguable exceptions of ``From:'' and ``Subject:'',
  283. duplicates
  284. of required headers are highly undesirable in news and cause difficulties
  285. for current implementations.
  286. RFC 1036 vaguely implies that the required headers are expected to be
  287. unique, but never says this.
  288. This needs to be made much more precise.
  289. C News
  290. takes a strict position and rejects articles with duplicate
  291. required headers.
  292.