[ntp:questions] PPS only configuration

unruh unruh at invalid.ca
Fri Feb 22 00:00:59 UTC 2013


On 2013-02-21, Mike S <mikes at flatsurface.com> wrote:
> On 2/21/2013 8:52 AM, Brian Utterback wrote:
>> Having said that, I note that Ed Mischanko's mailer is not sending
>> text/plain flowed. So unruh has a point in that case.
>>
>> On 2/21/2013 8:38 AM, Brian Utterback wrote:
>>> Hate to get into a religious war here, but there is a hard, factual
>>> standard here. RFC2646 which defines the MIME type text/plain format
>>> parameter.
>
> RFC2646 isn't a standard. It's an RFC, just like RFC1149. The standard 
> is STD11 (from RFC822). It places no restriction on the length of lines 
> in the body. The planned replacement (draft standard) is RFC5322, which 
> is quite clear that an MUA which can't handle long lines is 
> "non-conformant."
>
> "2.1.1.  Line Length Limits
>
>     There are two limits that this specification places on the number of
>     characters in a line.  Each line of characters MUST be no more than
>     998 characters, and SHOULD be no more than 78 characters, excluding
>     the CRLF.

Note the "SHOULD"

>
>     The 998 character limit is due to limitations in many implementations
>     that send, receive, or store IMF messages which simply cannot handle
>     more than 998 characters on a line.  Receiving implementations would
>     do well to handle an arbitrarily large number of characters in a line
>     for robustness sake.  However, there are so many implementations that
>     (in compliance with the transport requirements of [RFC5321]) do not
>     accept messages containing more than 1000 characters including the CR
>     and LF per line, it is important for implementations not to create
>     such messages.
>
>     The more conservative 78 character recommendation is to accommodate
>     the many implementations of user interfaces that display these
>     messages which may truncate, or disastrously wrap, the display of
>     more than 78 characters per line, in spite of the fact that such
>     implementations are non-conformant to the intent of this
>     specification (and that of [RFC5321] if they actually cause
>     information to be lost)."

note the "disasterously wrap" statement. Thus for example slrn does wrap
the lines. And if the end of the line occurs in the middle of a word,
tough. And there are others that do that. 


Note that rmc 5322 is 2008. Many of the news readers are older than
that. 




More information about the questions mailing list