Prev: Localized "Yes/No" strings
Next: RANT: Microsoft's Team Foundation Server
From: Hector Santos on 23 Jan 2010 01:22
tanix wrote:

> In article <uXeLD$0mKHA.5700(a)TK2MSFTNGP04.phx.gbl>, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>> Ha!
>>
>> This is so funny. Tanix mail reader is not wrapping RFC 3522
>> Referenecs: line and it allowing 1 single long line of 1024 characters
>>
>> The NNTP Server MS is using to host this newsgroup is barfing (and
>> properly so) with the illegal line (see below):
>
>> Either your mail reader,
>
> I am proud for you!!!!!!!!!!!!!!!!!!!!!!!!
> Except I do not read any RFC that is above around 2000.
> Sorry to tell you that.
>
> But even if I read it, my "mail reader" is not up to snuff
> I guess...

Glad you accept what is. Mark of a good programmer that accepts
whatever comes with it. Don't feel bad because I've seen this in
others as well. Everything is fine until it comes across a deep mail
thread with a long references ids list.

The practical limit is 1024. The old axiom to follow is to be liberal
in what you accept, be conservative in what you send. So even if your
own program can handle unlimited asciiz strings, you can't presume the
external world will be designed the same.

That said, the standard as it is currently defined in updated
specification RFC 3522 section 2.1.1:

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.

That has not change since 2000 (RFC 2822). In the original, RFC 822 it
was not explicitly defined however, think of the day of how people
design this stuff with 80x25 console screens or "PUNCH CARD"
mentality, and it was naturally to think a limit was 78/79 characters
(to avoid a natural CR/LF) if only because it was printable and
viewable to the naked eye. :)

The solution is simple. When you rewrite the References header in a
reply, check for the limits and create continuation lines which is a
simply adding a white space (WSP), a space or tab, on the next line:

Header1: xxxxxxxxxxxxx xxxxxxxxxxxxxxx .........
WSP xxxxxxxxxxxxxxxxxxxxx
WSP xxxxxxxxxxxxxxxxxxxxx
WSP xxxxxxxxxxxxxxxxxxxxx
WSP xxxxxxxxxxxxxxxxxxxxx
WSP xxxxxxxxxxxxxxxxxxxxx


--
HLS
From: tanix on 23 Jan 2010 08:08
In article <emmdvR$mKHA.5552(a)TK2MSFTNGP05.phx.gbl>, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>tanix wrote:
>
>> In article <uXeLD$0mKHA.5700(a)TK2MSFTNGP04.phx.gbl>, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>>> Ha!
>>>
>>> This is so funny. Tanix mail reader is not wrapping RFC 3522
>>> Referenecs: line and it allowing 1 single long line of 1024 characters
>>>
>>> The NNTP Server MS is using to host this newsgroup is barfing (and
>>> properly so) with the illegal line (see below):
>>
>>> Either your mail reader,
>>
>> I am proud for you!!!!!!!!!!!!!!!!!!!!!!!!
>> Except I do not read any RFC that is above around 2000.
>> Sorry to tell you that.
>>
>> But even if I read it, my "mail reader" is not up to snuff
>> I guess...
>
>Glad you accept what is. Mark of a good programmer that accepts
>whatever comes with it. Don't feel bad because I've seen this in
>others as well. Everything is fine until it comes across a deep mail
>thread with a long references ids list.

Well, putting a joke aside, you see, this article appears on Usenet
even though it might be on a mailing list.

So, I am using a very nice Usenet client and I am fully aware of the
line length limitation. There is no possibility for me to generate
ANY NNTP articles with lines longer than 70 characters. Because that
is my opinion on that. All the lines that are longer than 70 chars,
if followed up, will become longer by at least 1 character per
followup level.

Also, I do not use Subject: headers longer than 79 character.
So...

>The practical limit is 1024. The old axiom to follow is to be liberal
>in what you accept, be conservative in what you send. So even if your
>own program can handle unlimited asciiz strings, you can't presume the
>external world will be designed the same.
>
>That said, the standard as it is currently defined in updated
>specification RFC 3522 section 2.1.1:
>
>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.

Thanks. I did read it now and I do follow this convention.

>That has not change since 2000 (RFC 2822). In the original, RFC 822

Well, you have to consider the RFC 1034 if I recall correctly.
That one is the main NNTP standard.
I am reading your post via NNTP client.

Sorry, I have to get back to a pile of things I need to do.
Cya.

> it
>was not explicitly defined however, think of the day of how people
>design this stuff with 80x25 console screens or "PUNCH CARD"
>mentality, and it was naturally to think a limit was 78/79 characters
>(to avoid a natural CR/LF) if only because it was printable and
>viewable to the naked eye. :)
>
>The solution is simple. When you rewrite the References header in a
>reply, check for the limits and create continuation lines which is a
>simply adding a white space (WSP), a space or tab, on the next line:
>
> Header1: xxxxxxxxxxxxx xxxxxxxxxxxxxxx .........
> WSP xxxxxxxxxxxxxxxxxxxxx
> WSP xxxxxxxxxxxxxxxxxxxxx
> WSP xxxxxxxxxxxxxxxxxxxxx
> WSP xxxxxxxxxxxxxxxxxxxxx
> WSP xxxxxxxxxxxxxxxxxxxxx
>
>

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP,
organized by major topics of language, tools, methods, techniques.

From: Hector Santos on 23 Jan 2010 09:22

tanix wrote:

>> Glad you accept what is. Mark of a good programmer that accepts
>> whatever comes with it. Don't feel bad because I've seen this in
>> others as well. Everything is fine until it comes across a deep mail
>> thread with a long references ids list.
>
> Well, putting a joke aside, you see, this article appears on Usenet
> even though it might be on a mailing list.
>
> So, I am using a very nice Usenet client and I am fully aware of the
> line length limitation. There is no possibility for me to generate
> ANY NNTP articles with lines longer than 70 characters. Because that
> is my opinion on that. All the lines that are longer than 70 chars,
> if followed up, will become longer by at least 1 character per
> followup level.


Doesn't matter. It is still RFC 3522 Mail Format which applies to all
internet mail protocols, including usenet which is NNTP and mailing
list which is email - all the same thing.

> Thanks. I did read it now and I do follow this convention.


So you are back to denial?

> Well, you have to consider the RFC 1034 if I recall correctly.
> That one is the main NNTP standard.

> I am reading your post via NNTP client.

Read above - please follow RFC 3822 standards when it comes to
internet mail - ALL FORMS!. You break things when you do it wrong.

You do realize no one can reply to your XP scheduler question (if they
wanted to) because the HOST will reject a response to your broken
original RFC message?

--
HLS
First  |  Prev  | 
Pages: 1 2
Prev: Localized "Yes/No" strings
Next: RANT: Microsoft's Team Foundation Server