ietf-822
[Top] [All Lists]

Re: non-ASCII in headers

1991-10-03 01:14:31
On Wed, 2 Oct 1991 10:54:51 -0700 (PDT) you said:
    Headers are something else entirely.  Contrary to popular belief, headers
are not for humans.

Hmmmm... That's not explicitly written in RFC 822 (and it does matter, since
there currently is a fundamentalist tendency in the reading of the holy
document). One could argue that 'structured' headers are obviously rigidly
defined to allow consumption by programs, but by no stretch of the imagination
can this reasoning be extended to 'unstructured' headers.

    It therefore must be deferred to a new RFC specifically to address this
issue.  I suggest you Europeans start writing up draft RFC's NOW.

Hu ho... The devil's advocate will understand that the full machinery of IETF
is now available to finish RFC-XXXX (which is nice, it does lots of things
it was not supposed to do when the work started), but that, if those europeans
want to have meaningful headers (something that is part of the original problem
RFC-XXXX was to solve), they will be on their own, except perhaps
that the rest of the world will be there to watch and flame. This is perhaps
a little strong, but it is exactly how I feel the tone of 'you Europeans'...

BTW : I never personnaly used or wrote a program using ISO 646 variants, either
in the header or in the body of a message. I am more and more tempted to use
ISO8859-1. Some have said it would break previously conforming implementations.
Hey, here is a little story :

RFC 822 once said :

      date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                  ;  e.g. 20 Jun 82

Wanting to sort the messages received, someone wrote a program to parse dates
(remember, structured headers are obviously for program consumption). Figuring
that a year has 366 days at most, and 100 years of course 36600), she decided
to put the result in a 16-bit unsigned integer. Everything was fine. From
time to time some beatnick would send a date containing a four digit year, and
the program would then burst in flames, but, of course, a little message to
the culprit with a citation of the proper passage of RFC822 solved the problem
instantly.

Then came RFC1123 :

       5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5

          The syntax for the date is hereby changed to:

             date = 1*2DIGIT month 2*4DIGIT

          All mail software SHOULD use 4-digit years in dates, to ease

And now that perfectly conformant implementation is BROKEN.......

Do religious arguments really work ?                         /AF

<Prev in Thread] Current Thread [Next in Thread>