OT: Long lines in email (was: Re: special bg color)

[Boyd Stephen Smith Jr.]

In <pan.2009.12.24.21.46.50 at cox.net>, Duncan wrote:
>Boyd Stephen Smith Jr. posted on Thu, 24 Dec 2009 10:16:14 -0600 as
>
>excerpted:
>> In <20091224085352.403b4f3a at o>, spir wrote:
>>>Matthew Woehlke dixit:
>>>> Also you might want to consider fixing your mailer to wrap long lines
>>>> properly (or using a mailer that does).
>>>
>>>My mail client is correctly set to soft-wrap long lines, instead of
>>> hard-wrapping (inserting newlines) them, so that text nicely adapt to
>>> reader-chosen width (*).
>>
>> Your client is doing it wrong, then.  If you client would like to
>> soft-wrap lines, it should follow conventions established in RFC 3676
>> (format=flowed). Currently your client is sending a mail message with
>> lines longer than 80 characters, which is a violation RFC 5322 (Internet
>> Message Format).
>
>It's not a violation, as long as the MUST requirement of no more than 998
>characters per line (1000 minus the terminating CRLF sequence) is met.
>It may not meet the SHOULD of 78 chars, but it DOES meet the MUST of 998
>chars.  Quoting the relevant section 2.1.1 of the RFC you named:

It is a violation to not follow a SHOULD unless it is documented and 
rationalized.  Just because it is not an *absolute* requirement does not mean 
that doing it otherwise for no good reason is not wrong.

From RFC 2190:
"3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

As opposed to:
"5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)"

Note that there is no requirement for an implementation that follows a SHOULD 
to support interoperate with an implementation that chooses not to follow a 
SHOULD.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss at iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20091224/e27c1bc3/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.