[ntp:questions] PPS only configuration

Richard B. Gilbert rgilbert88 at comcast.net
Tue Feb 26 16:05:15 UTC 2013

On 2/21/2013 1:08 PM, Mike S 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.
>     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)."

I think that many hardware terminals e.g. VT100 or VT320 do not handle 
long lines well.

I can't see any reason why anyone would need to send more than 132 
characters in one line of text!

You may have noted that books, magazines and newspapers limit their line 

There are sound reasons for that!  So PLEASE take your nine hundred 
character line and break it up!

More information about the questions mailing list