Subject: Re: #1053 Relationship to RFC 2822 - suggestion

From: John Stanley <[email-masked]>
Date: Mon, 15 Aug 2005 11:16:46 -0700 (PDT)

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>Reality interrupt....

You mean "irrelevancy interrupt".

>Real programs will do what the people who implement them program.
>Real implementors listen to customers.

We are talking about how a specific software system is supposed to 
function. It is irrelevant if people write software that is 
non-conforming. 

Either you are talking to NEWS systems and assume they conform to the 
standard, or you are talking to /dev/random and have NO hope of knowing 
just what kind of gibberish is being handed to you.

If this "real programs" nonsense is going to be the driving force of this
working group, then we might as well stop now, since we will be unable to
require any specific behaviour or have any idea of what the incoming 
"news" message is going to look like. After all, "real implementors" 
listen to customers and not the standards, don't they?

>If they conclude that their support costs are minimized by article 
>mangling on broken articles, article mangling will be written into server 
>software.

And the first time someone writes an ARMM demon they learn that "fixing"
things isn't as simple as they thought.

>But mandating something that we know will be ignored...? Not fun.

What lunacy. We certainly can say how a conforming application operates,
and that non-conforming applications are OUTSIDE THE SCOPE OF THIS GROUP.
Once you say they are OUTSIDE THE SCOPE OF THIS GROUP, you've lost any
right to specify HOW they operate. Non-conforming agents (which are thus
NOT news agents) can do whatever they please with articles, except call 
them news articles. Conforming agents MUST NOT "fix" broken articles, 
because "broken articles" do not exist.

Would you like a simple example of why not? Ok, two agents out there in
"real space" decide they want to implement message id's differently, and 
both also happen to feel that truncating the path is ok. "Hey, A, your 
message id is bogus, I'll 'fix' it by inserting one of my own." "Hey,
B, your message id is bogus, I'll 'fix' it... and I'll fix the Date: 
while I'm at it, to make sure this fixed version propogates." Do the words 
"message loop" mean anything?

Henry Spencer <henry@xxxxxxxxxxxxx>:

>The best solution really is to outlaw all such (post-injection,
>non-Path/Xref) changes, whether the article is conforming or not. 

If it is non-conforming, it is not an article. As a non-article, you do 
not know what it contains, and "fixing" it is impossible. That's why
Henry is right -- "fixing" is prohibited.

Path is a known "modification" that we define, it is not a "fix". XRef is 
a known modification that we define, it is not a "fix". OTH, converting
the text from HTML into simple text is NOT a modification we define, and
thus it is a "fix" and thus prohibited.

---

From: John Stanley <[email-masked]>
Date: Mon, 15 Aug 2005 11:51:10 -0700 (PDT)

Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx>:

>>"Both" and "as applicable" are contradictions. "Both" means both apply,
>>and there is no "if" or "as".

>If, for a particular ABNF construct, only one ABNF exists, only one can 
>apply.

Then "both" is not correct. You cannot have a "both" when only one exists.

> Better term for saying that than "as applicable"?

"Articles must conform to the ABNF specified in RFC2822 unless superceded
by ABNF in this standard."

(It is assumed that conforming implementations will conform to the ABNF
we list here; it is only the RFC2822 ABNF that we need an explicit link 
to.)