home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / headers / 423 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  2.7 KB
  1. Xref: sparky comp.mail.headers:423 comp.mail.uucp:2509
  2. Path: sparky!uunet!psgrain!hippo!ee.und.ac.za!tplinfm
  3. From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
  4. Newsgroups: comp.mail.headers,comp.mail.uucp
  5. Subject: Re: Interpretation of RFC-822
  6. Followup-To: comp.mail.headers
  7. Date: 4 Jan 1993 09:59:52 +0200
  8. Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
  9. Lines: 41
  10. Message-ID: <1i8qpoINNrql@daisy.ee.und.ac.za>
  11. References: <yLmTwB4w165w@valinor.mythical.com>
  12. NNTP-Posting-Host: daisy.ee.und.ac.za
  13. Keywords: whitespace, structured headers, destination
  14.  
  15. [redirecting to comp.mail.headers  --apb]
  16.  
  17. In article <yLmTwB4w165w@valinor.mythical.com> in comp.mail.uucp,
  18. stu@valinor.mythical.com (Stu Labovitz) writes:
  19. > Now that we've covered what I believe are the relevant sections of the
  20. > RFC, here's the question:  Does RFC #822 provide limits (either minimum or
  21. > maximum) upon the number of SPACE characters that separate the "To:" from
  22. > the mailbox on the destination line?  Must there be at least one SPACE,
  23. > and is there any reasonable interpretation to prevent the existance of
  24. > more than one SPACE?
  25.  
  26. There are no limits in RFC822.  RFC821 specifies a maximum line length
  27. of 1000 chars (a sender may not transmit longer lines, but a receiver
  28. is encouraged to accept longer lines).
  29.  
  30. RFC822 section 3.1.4 says that the free insertion of linear-white-space
  31. is permitted between lexical tokens.  A cursory reading of this section
  32. may suggest that it applies only to structured field bodies, but I
  33. believe that the same rule applies to space between the field-name
  34. and the colon, and to space between the colon and the first token in
  35. the field-body.  I believe that this position is supported by clues
  36. in section 1.1 ("The formal definition is divided into four levels ...
  37. the second level describes basic lexical analysers that feed tokens to
  38. higher-level parsers"), section 3.1.2 ("Field names, unstructured field
  39. bodies and structured field bodies are eached scanned by their own,
  40. independent \"lexical\" analyzers"), sections A.3.1 and A.3.2 (examples
  41. in which there is no space between the field-name and the colon, and a
  42. variable amount of space after the colon), and section A.3.3 (an example
  43. in which there is space between the field-name and the colon).
  44.  
  45. In other words, if we consider the  definition of a field,
  46.  
  47.     field          =       field-name ":" [ field-body ] CRLF
  48.  
  49. we see that the field-name, the colon, and the first token of the
  50. field-body are three separate tokens, which may be separated by any
  51. amount of linear-white-space, including no space at all.
  52.  
  53. --apb
  54. Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
  55. RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
  56.