[ntp:questions] PPS only configuration

Brian Utterback brian.utterback at oracle.com
Thu Feb 21 19:16:25 UTC 2013


I know that it is an RFC, but it does say that it is standards track and 
there doesn't seem to be a full standard already that covers the same 
info. However, STD11 is not helpful in this argument. It is not covering 
the presentation of the message, only its transport. I don't believe 
that unruh is saying that his mailer cannot handle the long lines, he is 
saying that his mailer displays long lines on the screen as long lines. 
The RFC I referred to also is basically talking about the transport 
format of the message, but does address how they should be presented on 
screen as well.

Now, if you don't like RFC2646, you might say it's not a standard and 
that you won't follow it, but I don't think you should get a lot of 
sympathy, just as if you decided that you were going to ignore RFC 1305 
because it isn't a standard.

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)."
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list