Subject: #1022 Summary: Should dot be permitted in phrases?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Jun 2005 13:13:20 +0200

Of the flurry of messages on this subject line, I found exactly two 
responses that pertained to the subject of the original ticket:

- Charles would like to somehow elevate obs-phrase (which allows dot) from 
the "MAY accept/MUST NOT generate" implied by the current text to a status 
that says "MUST accept", and either SHOULD NOT or MUST NOT generate.

- Bruce Lilly argues against a deviation (I think).

Are these the only two voices on the subject?

I'm opening another ticket on the issue of UT in timezones.

                          Harald

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 12:04:08 -0700

> Are these the only two voices on the subject?

Deviating from RFC 2822 seems *really* pointless here.  Although, again,
this is one of those cases where no standard describes the crap that
people currently use in From headers and that news software accepts.  INN
is almost alone in even bothering to look for something that looks like an
e-mail address, and it only does that on posting.  Things like:

    From: No one

are common-place.  So arguing over including or not including the period
seems like a waste of time; unless we're going to bless "use whatever you
want," (which I'm not arguing in favor of) no deviation from RFC 2822 is
going to get us close enough to existing practice to be worth the pain.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 19:14:01 -0400

> - Bruce Lilly argues against a deviation (I think).

To clarify, my strong preference is "exactly as RFC 2822".
I'm willing to entertain other options, so long as there is an
accompanying well-reasoned argument for a deviation from 2822.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 07:35:06 +0200

> accompanying well-reasoned argument for a deviation from 2822.

"exactly as RFC 2822" means changing the "MAY accept" for the obs-syntax in 
section 2.1 to a "MUST accept".

RFC 2822 section 1.3 says:

   Section 4 of this document specifies an "obsolete" syntax.  There are
   references in section 3 to these obsolete syntactic elements.  The
   rules of the obsolete syntax are elements that have appeared in
   earlier revisions of this standard or have previously been widely
   used in Internet messages.  As such, these elements MUST be
   interpreted by parsers of messages in order to be conformant to this
   standard.  However, since items in this syntax have been determined
   to be non-interoperable or to cause significant problems for
   recipients of messages, they MUST NOT be generated by creators of
   conformant messages.

Is this what you are arguing for when you say "exactly as RFC 2822"?
Or are you arguing that in the specific case of obs-phrase, USEFOR should 
say "MUST accept, but MUST NOT generate", just like RFC 2822 says?

(Repeat mantra: When arguing a point, plese specify what section you want 
changed, what text you want changes to, and what you want it changed to.)

                       Harald

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 08:36:40 -0400

> say "MUST accept, but MUST NOT generate", just like RFC 2822 says?

In the specific case of obs-phrase, the rules should be the same as
RFC 2822, but that need not be achieved by repeating what 2822 says --
indeed a simple reference to 2822 is preferable.  This particular
provision of 2822 is a parse-only provision made to accommodate
previously illegal but commonly generated syntax errors.  One WG
participant has made a big deal out of that minor point; it is clear
from 2822 text what the rationale is for its inclusion, as it is
clear that the obs- syntax is a parse grammar separate from the
generate grammar.

In general, as I have said many times, we should conform to 2822
(and other relevant RFCs), and the above is a particular instance
of that general principle.  That principle applies to various aspects
of our work including terminology (2822, MIME, FYIs 18 & 36, etc.) ,
message format, and so on.  The reasons for doing so have been discussed
in this WG many times by many participants and include:
 o the principle of least astonishment
 o backward compatibility with widely deployed, Standards Track
   protocols (e.g. IMAP) [I note that our charter specifies "with
   particular attention to backward compatibility"]
 o likelihood of achieving IETF consensus and passing IESG review
A sampling of relevant discussions from the WG archives:
 http://www.imc.org/ietf-usefor/2003/Feb/0209.html
 http://www.imc.org/ietf-usefor/2003/Feb/0374.html
 http://www.imc.org/ietf-usefor/2003/Feb/0493.html
 http://www.imc.org/ietf-usefor/2003/Feb/0827.html
 http://www.imc.org/ietf-usefor/2004/Jun/0370.html
----------- excerpts (not in web archive) -----------------
Subject: Re: Final Last Last Last Call
From: Andrew Gierth <[email-masked]>
Date: 01 Aug 2002 19:27:44 +0100
Message-ID: <[email-masked]>

[...]
Back in November last year I made this proposal:

----
  I propose the following major changes:

  1. Strike all basic syntax and punt it back to the mail standards.
  Remove any changes that would have the effect of allowing UTF-8 in
  headers meaningful to mail. Instead, explicitly provide for the use
  of UTF-8 in Newsgroups and Followup-To, and provide _exactly one_
  mapping to a format compatible with mail, to allow gateways to handle
  it, and to allow servers to reject Newsgroups lines which have been
  munged for mail purposes. As regards UTF-8 in other fields, point out
  that it should be a future direction, that there are currently issues
  with interoperability with mail, but that both standards should be
  aiming to migrate towards UTF-8 (or some such wording).

  2. Strike all statements of policy or default policy, and all
  statements that refer to actions of the administrator rather than the
  software. In a few of the cases it may be appropriate to substitute
  recommendations.

  3. Generally aim to reduce the document's size; it is far too big.

  4. Strike the new path stuff and standardise the existing practice.
  Reliance on '!' turns out to be _extremely_ widespread.
----

At the time, I count only four direct responses to this proposal:
expressions of agreement from Russ Allbery and Ralph Babel, and
disagreement from Henry Spencer and Charles Lindsey. Personally I
regard that as indicating pretty strongly that there is not, in fact,
a genuine consensus behind the current document, and the subsequent
(but months later) adoption of changes that parallel my proposal (1)
(but without the simplifying benefits of referring back to the mail
standards) adds weight to this.

-- 
Andrew.
--------------------------------------------------

> changed, what text you want changes to, and what you want it changed to.)

As in Andrew's comments, many of the issues are general and affect
multiple sections.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 15:40:34 +0200

--On 9. juni 2005 08:36 -0400 Bruce Lilly <[email-masked]> wrote:

>> (Repeat mantra: When arguing a point, plese specify what section you
>> want  changed, what text you want changes to, and what you want it
>> changed to.)
>

Then make multiple suggestions, or say "I suggest we make this change, and 
the following sections need to be changed because of that - details to be 
discussed when the basic change is accepted".

I can imagine a number of different ways in which section 2.1 of USEFOR 
could be formulated based on your comments. But you're the one who wants it 
changed (or, if I have misunderstood you, you don't want it changed). Until 
you propose a change, I can't tell.

                            Harald

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 11:17:46 -0400

> discussed when the basic change is accepted".

I suggest that we use standard terminology and section text as used in
the primary normative references and as documented in current Internet
FYI/BCP glossaries and guidelines (notably FYIs 18, 36, BCPs 14, 26, 72,
104) and relevant other guidelines and procedures (notably ID-checklist,
ID-Guidelines, "instructions to RFC Authors").

The following sections of USEFOR version -03 need to be changed because
of that - details to be discussed when the basic change is accepted:
  1.4, 1.5, 1.6, 2.1, 2.2, 2.3, 3, 3.1, 3.1.1, 3.1.2, 3.1.3, 3.1,4, 3.1.5,
  3.1.6, 3.1.7, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7,
  3.2.8, 3.2.9, 3.2.10, 3.2.11, 3.2.12, 3.2.13, 3.3, 3.3.1, maybe 4,
  probably 5, An IANA Considerations section is missing but REQUIRED
  (per ID-Guidelines and "Instructions to RFC Authors"), 6.2, Appendix A.

Note that most of the changes are small and could be performed automatically.
In other cases, a section needs to be moved (Appendices are supposed to
appear before references) or added (IANA Considerations).  Several of the
changes are due to requirements which are not currently met by the draft.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 11:34:02 -0400

> discussed when the basic change is accepted".

I suggest we conform as closely as possible to our primary normative
references and published extensions, and that any deviations are
clearly indicated via the use of Implementation notes of the general
form suggested here by Mark Crispin:
    http://www.imc.org/ietf-usefor/2003/Feb/0493.html
and that use of BCP 14 imperatives in conjunction with any such
deviations in fact conform to the usage requirements in BCP 14.

The following sections need to be changed because of that - details
to be discussed when the basic change is accepted:
  (probably 1.4), 2.1, 2.2, (small note in 3.6), 3.1.1, 3.1.2,
  3.1.3, 3.1.4, 3.2, 3.2.1, 3.2.3, 3.2.5

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 11:47:02 -0400

> discussed when the basic change is accepted".

I suggest that no later than the publication of the next draft revision,
the editors carefully spell-check, proofread, and edit for consistency
the draft (e.g. section cross-references are correct, references listed
in the references sections are actually referenced, informative/normative
references are categorized correctly, etc.).

The following excerpts illustrate some of the issues; these issues should
be corrected by the Editors before being presented to the WG:

1.2: "An best" is not English

ISO 3166 is used normatively in section 3.2.6 but is listed as informative.

The suggestion of course affects the entire draft.

---

From: Henry Spencer <[email-masked]>
Date: Thu, 9 Jun 2005 11:50:37 -0400 (EDT)

On Thu, 9 Jun 2005, Bruce Lilly wrote:
> references and published extensions...
> to be discussed when the basic change is accepted...

Personally, I find it impossible to evaluate this suggestion without
more detail.  The suggestion as phrased is nearly meaningless, given
that there is no clear indication of what is to be changed or why.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 11:55:07 -0400

> discussed when the basic change is accepted".

I suggest that the draft text be revised to conform to the Chair's defined
scope as presented in
  http://www.imc.org/ietf-usefor/2004/Jun/0370.html
specifically, that new fields must clearly be marked as such.

The following sections need to be changed because of that - details to be
discussed when the basic change (to the draft, no change in policy is
suggested) is reiterated:
  3.2.11, 3.2.12, 3.2.13

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 09 Jun 2005 12:18:00 -0400

> of that - details to be discussed when the basic change is accepted:

Bruce listed all sections of version -03, except for

1.  Introduction
1.1  Basic Concepts
1.2  Scope
1.3  Requirements Notation
2.  Format
6.1  Normative References

Links to separated sections of version 03 are available at:

     http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/

Each page has a diff to the immediately previous version, and links
to older and newer versions.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 09 Jun 2005 12:22:18 -0400

Bruce Lilly wrote:

>   (probably 1.4), 
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Syntax_Notation.htm

> 2.1
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Base.htm

> 2.2
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Headers.htm

> (small note in 3.6)
Bruce, I can find no section with that number.

> 3.1.1
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/From.htm

> 3.1.2,
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Date.htm

> 3.1.3
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Message-ID.htm

 > 3.1.4
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Subject.htm

 > 3.2
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Optional_Headers.htm

 > 3.2.1
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/References.htm

 > 3.2.3
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Expires.htm

 > 3.2.5
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Supersedes.htm

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 09 Jun 2005 12:23:53 -0400

Bruce Lilly wrote:

>   3.2.11
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Archive.htm

> 3.2.12
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/User-Agent.htm

> 3.2.13
http://www.mibsoftware.com/userkt/usefor/usefor-usefor-03/Injection-Info.htm

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 19:03:30 +0200

I have created ticket #1030 with this text.

I will attempt to attach any suggestions for specific modifications to the 
mentioned sections on this basis to that ticket; in order to make this 
easier, please keep the subject line with #1030 in it.

I'm still waiting to hear what specific changes to 2.1 Bruce is suggesting.

--On torsdag, juni 09, 2005 11:34:02 -0400 Bruce Lilly <[email-masked]> 
wrote:

>> Then make multiple suggestions, or say "I suggest we make this change,
>> and  the following sections need to be changed because of that - details
>> to be  discussed when the basic change is accepted".
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 19:15:50 +0200

I have assigned ticket #1031 to this suggestion.

FYI, the numbers quoted are:

FYI 18 - RFC 1983 Internet Users' Glossary (1996)
FYI 36 - RFC 2828 Internet Security Glossary (2000)
BCP 14 - RFC 2119 Key words for use in RFCs to Indicate Requirement Levels
BCP 26 - RFC 2434 Guidelines for Writing an IANA Considerations Section
                  in RFCs
BCP 72 - RFC 3552 Guidelines for Writing RFC Text on Security
                  Considerations
BCP 104 - RFC 4084 Terminology for Describing Internet Connectivity

I am looking forward to your specific suggestions on changes based on these 
documents.

This still does NOT qualify as suggesting a text change.

--On torsdag, juni 09, 2005 11:17:46 -0400 Bruce Lilly <[email-masked]> 
wrote:

> Note that most of the changes are small and could be performed
> automatically. In other cases, a section needs to be moved (Appendices
> are supposed to appear before references) or added (IANA Considerations).
> Several of the changes are due to requirements which are not currently
> met by the draft.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 19:20:30 +0200

I have assigned ticket #1032 to this issue.

However, I think (personal opinion) that a better approach is to add an 
appendix to the document stating how the format differs from the one 
described by RFC 1036.

                             Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Thu, 09 Jun 2005 14:31:49 -0400

Harald Tveit Alvestrand wrote:

> I am looking forward to your specific suggestions on changes based on 
> these documents.
> 

Huh?

Bruce did a huge favor in reviewing and pointing out why the drafts
don't resemble any other IETF work-product.  That review was a lot of work
already.  Bruce provided a list of section numbers.

Why is it acceptable to require that Bruce rewrite the sections before
entering tickets for every one of those sections?  Bruce isn't editor.

Many of the issues have been raised before.  Some of the changes are
blatantly obvious, like the pointless redefinition of RFC2822 terms
in USEFOR-04 section 2.

If the chair and editor can't see the problems in the text now, then what
criteria will be used to evaluate any rewritten versions?  Just curious.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 9 Jun 2005 16:14:05 GMT

>accompanying well-reasoned argument for a deviation from 2822.

I think everyone agrees MUST accept.

The issue is SHOULD NOT vs MUST NOT for generate.

The argument for MUST NOT is that it follows RFC 2822 exactly.

The argument for SHOULD NOT is that we may be choosing SHOULD NOT for the
References and Newsgroups folding cases, in which case there is some merit
in being consistent across all three.

And I am assuming that we are discussing only <obs-phrase> (aka
<extended-phrase>) here.

I would be totally opposed to opening the floodgates to the obs- syntax
as a whole. Just the two cases we are discussing - <obs-phrase> and
<obs-zone>.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Thu, 09 Jun 2005 13:08:46 -0700

> don't resemble any other IETF work-product.  That review was a lot of
> work already.  Bruce provided a list of section numbers.

> entering tickets for every one of those sections?  Bruce isn't editor.

In those messages, he wasn't sufficiently specific about what he wanted
changed for me to have any idea what he was talking about without applying
knowledge from previous discussions (sometimes years back).  He doesn't
have to rewrite the sections, but he should at least list specifically
what terms he wants changed and outline what textual changes he wants
made.

> Many of the issues have been raised before.

Yes, I agree with this, but to get the information into the ticket it
needs to be summarized without assuming people have read all the previous
messages.

> Some of the changes are blatantly obvious, like the pointless
> redefinition of RFC2822 terms in USEFOR-04 section 2.

When they're blatantly obvious, they're very easy to list.

> If the chair and editor can't see the problems in the text now, then
> what criteria will be used to evaluate any rewritten versions?

I think you're putting words into the chair's mouth.  We're not talking
about his personal ability to see the desired changes; we're talking about
a procedure that we were asked to follow in making changes.  Proposals
need to be specific enough that everyone knows exactly what is being
proposed to change.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Jun 2005 23:25:10 +0200

> The issue is SHOULD NOT vs MUST NOT for generate.

Charles, may I remind you again:

the current wording (2.1) is MAY accept.

What wording change do you propose?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 04:03:02 +0200

> ISO 3166 is used normatively in section 3.2.6 but is listed

ISO 3166:1988 3rd ed. :-(  Maybe we can use the region codes
in the new LTRU registry, it's probably ready for take-off
before USEFOR.  I'll try to watch this point.  In any case of
course "normative", but no debates about CS 1988 please.

While I'm at it here's another LTRU issue:  The "worst" encoded
word for 3066bis could be something like:

Subject:
 =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-831-variant1-variant2?Q?a?=
....5...10....5...20....5...30....5...40....5...50....5...60....5...70....5.

That's ridiculous, but "legal" under 2047 / 2231 / 3066bis.

Now let's assume that it's the first character of a word where
the language tag makes sense.  And it's the first character of
the Subject.  And it hits a mail2news gateway.  Any attempt to
split one letter fails.

There are some rules in 3066bis allowing to strip "-variant2":

Subject: =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-831-variant1?Q?a?=
....5...10....5...20....5...30....5...40....5...50....5...60....5...70....5.

Good enough, but do we expect this clever trick from gateways ?

Or should we just offer a way to force compatibility with our
rules by adding a "dummy" word in the 1st line of the Subject ?

Subject: =?utf-8?Q?=EF=BF=BE?=
 =?pc-multilingual-850+euro*lng-exa-exb-exc-Latn-831-variant1-variant2?Q?a?=
....5...10....5...20....5...30....5...40....5...50....5...60....5...70....5.

Or what should the poor mail2news gateway do ?  Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Jun 2005 08:30:40 +0200

> already.  Bruce provided a list of section numbers.

Forrest,

please tell me in which way (picking some random, and short, documents) 
draft-ietf-dnsop-serverid-04 and draft-ietf-sip-sctp-06 resemble each other 
more than either resemble draft-ietf-usefor-usefor-04.

After 8 years on the IESG reading drafts, I found nothing special about 
draft-ietf-usefor-usefor-04 that would warrant the "don't resemble any 
other IETF work-product" claim. So it seems you have different criteria 
than mine.

> criteria will be used to evaluate any rewritten versions?  Just curious.

I wonder about that too.

Furthermore, since Bruce has raised a lot of objections to a lot of drafts 
over the time I've observed him, and has seen some of those objections 
rejected, it's clear that the IETF can decide to approve something that 
Bruce does not like.

I don't know of any simpler way than to get specific text change proposals 
on the table, debate those on the open mailing list, and try to decide what 
the consensus of the WG is.

Painful, yes. Demands text proposals, yes.
Now, you seem to have a specific objection to:

   This specification uses the terms "header", "header name", and
   "header content" which are synonymous with the [RFC2822] terms
   "header field", "field name", and "field body" respectively.

Are you making a proposal for a specific text change to delete this 
paragraph and change the remaining text to use the RFC 2822 synonyms? 
That's an actionable item; "some of the changes are blatantly obvious" is 
not.

(the word "header" occurs approx. 137 times in usefor-04. I think it's 
makework to do the search-and-replace, but if I've interpreted you 
correctly, you think differently. Please argue your case.)

                      Harald

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 09:00:52 -0400

> other IETF work-product" claim. So it seems you have different criteria 

I can't recall seeing a draft other than the one under discussion and
its predecessors that has anything like
"When we say 'white' we mean black, and when we say 'black' we mean red,
and when we say 'red' we mean green.  We won't tell you what we really
mean when we say 'green' -- sometimes it might mean green and sometimes it
might mean something else."
Which is basically what that draft says (except it's not nearly as honest
about the last part).
 
[...]
> > criteria will be used to evaluate any rewritten versions?  Just curious.

That's a strange remark.  I think it's reasonable to state what the
criteria for evaluating comments and determining consensus are before
asking people to jump through ever higher hoops.  For reference, a past
WG Chair had the following to say, and if I recall correctly, Alexey
has agreed:
  On the topic of voting: Especially on this topic, I think voting 
  would be stupid. The decision is about rough consensus. One screaming 
  person does not indicate that there is no rough consensus, but one or 
  two well-reasoned arguments against a screaming huge crowd does. And 
  a huge number of "I'd prefer X, but I couldn't care less" votes 
  versus 2 or 3 well-argued "X will spell doom for the Internet, and Y 
  will save it" votes *is* rough consensus for Y over X. So voting 
  generally doesn't help me decide one way or the other that there is 
  rough consensus.
and
  As I said in the last message, voting (especially on topics where 
  there are only a few voices who are making well-reasoned arguments) 
  is often a lousy way to judge consensus because you can have a huge 
  number of people vote for a position they don't feel strongly about. 
  In the case of this particular issue, I think the chair taking a 
  rough stab at what appears to be consensus and waiting for screams of 
  horror is going to be much more productive than voting.

We've seen a recently declared "(VERY) rough consensus", and you have
referred to your May 27 message which repeats snippets of comments,
few of which can be said to constitute "well-reasoned arguments".  It's
difficult to guess what criteria in fact were used to conclude the
"(VERY) rough consensus", and there have been "screams of horror".

I don't think it's unreasonable to ask if the criteria we have been
using for the past couple of years have changed, and if so, what are
the new criteria.  Ideally we would have had that discussion up front,
but better late than never...
 
> the consensus of the WG is.

That's only part of it.  It ought to be followed by
o ensure that the Document Editor(s) faithfully record the WG consensus
o ensure that once recorded in the document based on WG consensus, the
  text is not arbitrarily changed without good cause, WG discussion, and
  WG consensus [may I suggest an explicit note in the draft text, to be
  commented out during RFC publication, indicating the date on which
  consensus was declared as a cautionary note against unintentional
  revision during editing]

If it isn't, there's little point in proceeding; we've seen the movie
before (indeed, we've been watching reruns for 8 years) and we know how
it turns out.
 
> Painful, yes. Demands text proposals, yes.

There's no point in specific *text* proposals (as distinct from a specific
principle, with text to be worked out later) if they're rejected out of hand
by Editorial fiat or if they're rewritten to change the meaning (or, for that
matter, if the text is nitpicked to death ignoring the principles).  All have
happened, and that is why people are reluctant to suggest specific text.

Now if the co-chairs are giving assurances that that won't continue to
happen ("Come on in; the water's fine"), one or two people might cautiously
dip a toe in the pool, and in the fullness of time somebody might actually
dive in if and when it really seems worthwhile.  Whether or not it's a bit
late for that is another matter.

> That's an actionable item;

With s/RFC 2822 synonyms/standard FYI 18 & RFC 2822 terms/ that sounds
like a great idea.

So, count that as one actionable item.  Following some clarifications
regarding methods of determining consensus and assurances that WG
consensus will be respected, there may be others.

> (the word "header" occurs approx. 137 times in usefor-04.

It wouldn't if the mix of standard and non-standard terminology that was
in -00 had been corrected when that was suggested instead of being changed
to exclusively non-standard terminology by Editorial fiat...

> I think it's  

See
http://www.imc.org/ietf-usefor/2004/Jul/0077.html
for a case that clear, consistent, and standard terminology matters.  The
goal of a technical specification is to enable implementers to produce
interoperable implementations, and the likelihood of that is diminished
if (any of)
a) the specification is ambiguous
b) the specification is self-inconsistent
c) implementers are forced to remember "in this document 'white' means
   black and 'black' means red, and 'red' means green, but I'm told 'it
   requires complete understanding and implementation of the normative
   references', in which 'white' means white, 'black' means black, and
   'red' means red"
d) there are conflicting definitions of "foo" (for one or more values
   of foo) between the document and its normative reference, with no
   clear indication of which definition has priority or why there is
   a difference
e) ABNF is self-inconsistent or ambiguous (or unchecked contrary to the
   requirement in ID-Guidelines) or conflicts with normative text
f) operational requirements impose the need for an efficient
   implementation, which is precluded by grammar or some normative
   requirement
g) the specification says "This document uses a cite by reference
   methodology, rather than repeating the contents of other standards,
   which could otherwise result in subtle differences and
   interoperability challenges", but the specification in fact repeats
   content of other specifications, introducing subtle (and not-so-subtle)
   differences and interoperability challenges.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Jun 2005 15:09:45 +0200

Bruce,

this is a warning. On list and for the record. You were already warned 
privately about insulting participants.

Your language is insulting to the editors, the chairs and the members of 
the working group who do not agree with you - as well as being just vague 
enough that it is not possible to figure out what exact text you are 
objecting to, and what you want it to say instead.

If you continue in this vein, I will remove your posting rights to this 
list.

                      Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 10 Jun 2005 09:14:41 -0400

> That's an actionable item; "some of the changes are blatantly obvious" 
> is not.
> 

In the future, hundreds of people will read these documents.  They
will be expected to be familiar with RFC2822.

Are you saying it is better to force every single one of those people
to learn new, pointless definitions just to understand Usefor, than have
one editor do 5 minutes of search and replace of "makework" now?

Is it OK to pretend that we are going to finish before RFC2822 gets
done?  They finished first, so we get to re-use what they have done,
not fight against it.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 10 Jun 2005 09:24:14 -0400

Harald Tveit Alvestrand wrote:

> the working group who do not agree with you - as well as being just 
> vague enough that it is not possible to figure out what exact text you 
> are objecting to, and what you want it to say instead.
> 

Bruce's "language" was insulting only if you consider criticism insult.

You are welcome to remove the posting rights of anyone in order
to finish the document the way you think best.  If you remove Bruce's
posting rights because you don't like what he says, then I see little
point in my participating further.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Jun 2005 16:00:31 +0200

After looing through draft-ietf-usefor-usefor-04, I've found that of the 
"redefined" terms:

"header name" occurs once.
"header content" occurs three times.

Is there anyone who objects to changing those to "field name" and "field 
body"?

If that's OK, we're left with whether "header" means one RFC 2822 header 
field (as in the current draft) or the entire part of the article before 
the blank line (as in RFC 2822).

(I'm somewhat unsure what a "header line" means - it isn't listed in the 
definitions, and is not used in 2822. I'm assuming that it's a line (as 
defined in RFC 2822) that occurs in the header (as defined in RFC 2822))

                            Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Jun 2005 16:11:52 GMT

>references are categorized correctly, etc.).

The Editors are well aware of many matters of form, boilerplate, division
of texts between USEFOR and USEPOR, and other nitpicks, etc. remain to be
done. But it is considered more important at the moment to get the
technical issues correct, so that at least each of USEFOR, USEPRO and
USEAGE can be made technically consistent.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 10 Jun 2005 12:43:16 -0400

> USEAGE can be made technically consistent.

When can we expect to see them in the ticket system?  There is no sense
using an issues tracking system for only some of the important issues.

80% of the benefit comes only by ensuring that it accurately represents
all open issues.

---

From: Henry Spencer <[email-masked]>
Date: Fri, 10 Jun 2005 12:50:29 -0400 (EDT)

> Is there anyone who objects to changing those to "field name" and "field 

We should be consistent:  either use the terminology that is common in
news, or use the RFC 2822 terminology from mail.  Changing *some* of the
terms will gain us nothing but confusion.  The fact that "header name" and
"header content" see little use doesn't mean they can be changed without
penalty; what it means is that keeping them consistent with any decision
about "header" is not a problem.  They should be changed if, and *only*
if, "header" is changed. 

> the blank line (as in RFC 2822).

I favor keeping the terminology that's in common use in news software and
news documentation.  The divergence from RFC 2822 is regrettable but it's
too late to fix it.  Changing to RFC 2822 terminology will increase the
readability of our document for people coming from the mail world, but
will reduce it for people already accustomed to the news world.  I submit
that for this document, the latter are more important.

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 10 Jun 2005 13:22:39 -0400

> that for this document, the latter are more important.

"More important" based on what criteria?

If RFC2822 were an informative reference, inconsistency might be understandable.

But since it is a base reference, there is NO WAY to read the USEFOR documents
without understanding RFC2822 first.

So that means that EVERYONE is "coming from email world."

Google searches indicate
    14,300 references for the term "RFC1036"
    45,300 for "RFC2822"
   997,000 for "RFC822"

Counting google references isn't a precise measure of anything.  But it
says something.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2005 19:53:02 +0200

Harald Tveit Alvestrand wrote:

> we're left with whether "header" means one RFC 2822 header
> field (as in the current draft) or the entire part of the
> article before the blank line (as in RFC 2822).

This <quote Bruce> "hacker slang" <unquote> is also defined
in RfC 2110:

|  Header    Field in a message or content heading specifying
|            the value of one attribute.

|  Heading   Part of a message or content before the first
|            CRLFCRLF, containing formatted fields with
|            attributes of the message or content.

In real life nobody says "header field", only we sometimes do,
because we are arrogant pseudo-scientific twits.  URI vs. URL
is another telltale.
                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Jun 2005 18:22:48 GMT

In <[email-masked]> Henry Spencer <[email-masked]> writes:

I hope I have attached the proper ticket number to this reply.

>that there is no clear indication of what is to be changed or why.

I think he is upset because we use the term "header" rather than "header
field" and "header name" rather than "field name".

I would point out that our drafts have always used this terminology (and
have carefully documented that usage).

RFC 1036 used the term "header" (though not consistently, since it
sometimes used "header line" - a quick look revealed no occurrence of
"field", though I have not grepped to confirm it).

Son-of-1036 used the term "header".

The NNTP draft, which has just completed its IETF Last Call period, uses the
term "header".

I move that we make no change to this long established practice.

NOTE that there is a technical problem with the term "header content" as
defined in USEFOR. I have suggested to Ken that he changes it to "header
body" throughout USEFOR, and I will define a term "semantic content"
(abbrevieted to "content") to cover the way that term is used in USEPRO.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Jun 2005 16:22:50 GMT

>What wording change do you propose?

In relation to the particular matter of <obs-phrase>, I wish to see MUST
accept.

I could live with either of SHOULD NOT or MUST NOT for generate.

My preference is that we should use SHOULD NOT/MUST NOT consistently for
the three cases of <obs-phrase>, <obs-zone> (or whatever part of it we
adopt) and Newsgroups folding, if it is possible to do so (it might not
be, because their priorities are somewhat different).

If you press me for an explicit choice, then it would be for SHOULD NOT in
all three cases.

---

From: Eivind Tagseth <[email-masked]>
Date: Fri, 10 Jun 2005 21:21:06 +0200

* Harald Tveit Alvestrand <[email-masked]> [2005-06-10 15:09:45 +0200]:

> Your language is insulting to the editors

I failed to see any insulting language in that message.  I failed to see
anything wrong with it at all...

Eivind

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Jun 2005 22:53:13 +0200

> 80% of the benefit comes only by ensuring that it accurately represents

I create tickets as I see specific issues raised on the mailing list.
There's no sense in raising a ticket to say that "organization" should 
really be spelled "organisation" (or vice versa).

---

From: Russ Allbery <[email-masked]>
Date: Fri, 10 Jun 2005 14:02:53 -0700

Harald Tveit Alvestrand <[email-masked]> writes:
> "Forrest J. Cavalier III" <[email-masked]> wrote:

> really be spelled "organisation" (or vice versa).

Agreed.  Let's not go overboard here.  It's pointless to spend much time
trying to fix typos and the like at this stage; we should do one pass once
the draft is in reasonably final shape.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 10 Jun 2005 17:37:12 -0400

> really be spelled "organisation" (or vice versa).

Being only 9 weeks out from a deadline in a group that works this slowly,
means there is no reason for delay in finding and fixing even the little
stuff.  (Or do you admit the 9 week deadline is a deathmarch anyway?)

Yes, creating a ticket can be more work than fixing a problem, but if
you STILL don't want to fix the problem now, then you have to create a
ticket.  When you use a Quality Control system only half way, you get
all the costs, and nearly none of the benefits.  Don't bother.

If you don't want lots of little tickets, can I can suggest to create
"Meta" tickets for things you consider "nuisance", and keep tacking
on everything you can think of as amendments.  It would be less work
than having multiple people raise the same issue, and have to respond
3 times with "Oh, that's not in the ticket system, but trust us,
we'll get to it.")

If you don't have everything in the ticket system, there is no way to
use it to get an idea of the work remaining.  If someone had everything in
the ticket system, and saw how much work on average to close each
issue when you use one-man one-vote consensus, you'd realize that 9 weeks
is a deathmarch.  Or it isn't.  How can you tell?

Further, are you certain that these things you want to postpone to cleanup
are merely nuisance?

1. If there are any documents misclassified as normative/informative,
or there are wrong cross-references, that isn't a nuisance problem.
Both change how you read the document, and can't be that hard to
get right.

2. You are asking volunteers to review this work.  They will stop when
they see problems like that, because they know it isn't ready for review.

(Also, I agree with John's comments about the mickey-mouse self-signed
SSL cert.  Doesn't everyone get all the phishing attempts that I
get. I am very careful about accepting CAs.)

I also agree with John's comments that the ticket system must not be
used for discussion.  It's just an accounting system.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Jun 2005 18:53:52 GMT

>> deviations in fact conform to the usage requirements in BCP 14.

Although possibly useful in some situations, such a blanket solution is
unlikely to be helpful. Each case needs to be considered on its merits. If
you have specific examples to suggest, then we can do so.

But from the examples of Mark Crispin's Implementation notes that I have
seen, they tend to be of the form "This is how Mark Crispin views this
problem, and he does not wish to be confused by the facts adduced by those
who have actual experience of it".

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 23:21:03 -0400

> This <quote Bruce> "hacker slang" <unquote> is also defined

2110 is obsoleted, and the obsoleting RFC has a multitude of problems
(which we here are not chartered to solve -- byt we can and should
fix the problems in our deliverables).

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 23:28:32 -0400

On Fri June 10 2005 12:50, Henry Spencer wrote:

> news, or use the RFC 2822 terminology from mail.

1. RFC 2822 isn't just "mail". This has been discussed before.
2. the standard definition of "header" appears in FYI 18, which is
   certainly not jst "mail"

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 10 Jun 2005 23:33:42 -0400

> have carefully documented that usage).

Sample quotes from draft-ietf-usefor-usefor-00.txt:

   User agents SHOULD support on receipt and MAY generate MIME extension
   header fields, 

   The "Message-ID:" field contains a single unique message identifier.

---

From: Henry Spencer <[email-masked]>
Date: Sat, 11 Jun 2005 01:30:08 -0400 (EDT)

> 1. RFC 2822 isn't just "mail". This has been discussed before.

It has indeed, and while a few people think RFC 2822 isn't "just mail",
others note that RFC 2822 explicitly says that it applies "within the
framework of 'electronic mail' messages".  It tries to be more widely
applicable, but hasn't entirely succeeded yet. 

In any case, there is no question that RFC 2822 derives from mail work and
that its terminology is that of mail, which is the specific issue being
talked about.  Please try to stay on topic. 

> 2. the standard definition of "header" appears in FYI 18, which is

FYI 18 (aka RFC 1983) gives two definitions for "header", one for the
header of a packet and one for the header of an "electronic mail message". 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Jun 2005 16:01:32 +0200

Bruce Lilly wrote:

> 1. RFC 2822 isn't just "mail".

It's a proposed standard.  I think we have already seen
that there are some issues with its relation to MIME, and
its idea of NO-WS-CTL in the header is plain wrong.

> 2. the standard definition of "header" appears in FYI 18

Yes, just below "hacker".  Please use RfC numbers, it took
me two attempts (1938, 1983) to check that you are really
talking about 1983.

RfC 1983 is obviously obsolete, US-idiosyncratic, and in
parts as irrelevant as RfC 1855.  It's a simple glossary,
it's no "standard terminology", unless you dare say so.

Among other obsolete crap it defines "uuencode", that won't
force us to remove MIME from USEFOR, or to sanction UUE.

                        TTFN, Frank

P.S., TTFN is defined in FYI 18.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Jun 2005 18:01:48 +0200

Bruce Lilly wrote:
 
> 2110 is obsoleted

Okay, I have now updated e.g. <http://purl.net/net/rfc/2110>
to show the RfC status (+ abstract + keywords) first instead
of directly jumping to the txt files.

If anybody used this PURL redirection (except from me ;-) to
get RfCs directly he just met Murphy.  Do you want a copy of
any flames ?

> the obsoleting RFC has a multitude of problems (which we 
> here are not chartered to solve -- byt we can and should

Nonsense like "header" vs. "header field" is irrelevant while
simple questions like "what is a newsgroup name" are unclear.

At least we have already solved "what is a msg-id" minus the
detail of the production names.  BTW, I hope you supoprt the...

       msg-id = "<" id-local "@" id-domain ">"

...style instead of <id-right> which could be almost anything.
 
                     Bye, Frank

---

From: Richard Clayton <[email-masked]>
Date: Sun, 12 Jun 2005 12:52:34 +0100

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>have carefully documented that usage).

Although I have sympathy for the view that this is continuing the
tradition of how "news" documentation is written, I think that's a
mistake :(

Considerable leverage is gained by defining "news" as a special case of
"mail" (albeit, I sometimes wonder if -- when the minutiae is debated at
such length -- the gain is entirely worth the pain).

Whilst we continue down that path then it behoves us to use the jargon
from "mail" in a consistent and user-friendly manner.

Although there may be mileage in saying "In this standard we use frooble
to mean 'some very long phrase that is hard to keep repeating'" I don't
think that it does anything other than create confusion to use a
substitute for quite short phrases AND what's more, to use a word
"header" that so closely resembles what is being substituted.

As a data point, I'm currently in the process of finally editing my PhD
thesis (yes, they let you do PhDs even at my advanced age!) and realised
that I'd been very sloppy with my own use of the word "header". It took
less than an hour to work through the document and fix every mention to
the correct 2822 jargon.  I really do not think that it reads any worse
now that I've done it, nor is it harder to understand for a neophyte.

>The NNTP draft, which has just completed its IETF Last Call period, uses the

of these three points, this is the _only_ one that would concern me (we
are, I trust, hoping to reach a situation where only historians consult
the other two documents, so who cares what they say?) ... so I checked
the documents recently exiting last call, which appear to be:

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-authinfo-09.txt

        which contains the single phrase "This may be accomplished, for
        example, by inserting headers in the posted articles ..."

        ie: trivial change to "header fields"

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-06.txt

        which doesn't contain "header" at all

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-streaming-05.txt

        this uses "headers" twice, both of which can easily be changed
        to "header fields"

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-base-27.txt

        this uses "header" extensively in 3.6 (relating to folding) and
        would require a moderate amount of work :-(  though in my view
        that work is mechanical and should not give rise to debate.

>I move that we make no change to this long established practice.

You can argue that both alternatives are "long established".

The question is what is best going forward. And there the choice appears
to be between creating significant consistency in the set of documents
that future implementors consult; and in doing some mechanical editing
to documents that are not yet set in stone (albeit some are already a
long way towards that state).

If we are still allowed to disrupt the smooth progress of the NNTP
documents then, in my view, that is what we should do.

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Jun 2005 02:01:00 +0200

Richard Clayton wrote:
 
> Whilst we continue down that path then it behoves us to use
> the jargon from "mail" in a consistent and user-friendly
> manner.

This "jargon" isn't limited to news, it's just what uers say
everywhere, mail, news, http, etc.  Generally this is obvious
from the context.  When I say "Accept-Language header", then it
is the "Accept-Language header field", what else could it be ?

Consistency is only important when there is a realistic chance
that readers get it wrong.  Talking about "header" when it's
actually only a "header field" could be dangerous.

The shorthand "header line" for "header field line" might be
critical, if a reader confuses "header line" (one line) and
"header field" (all lines).

Other shorthands like "header name" or "header content" or the
specific "From header" etc. are IMHO obvious, the long forms
are very artificial.  There's a time where you say "octet" or
"encoded character repertoire" etc. because it's important, but
there's also a time where "byte" or "charset" are good enough,
and clearer for casual readers not familiar with all details.

> The question is what is best going forward.

Get the technical essentials right, msg-id and newsgroup-name.
  
> If we are still allowed to disrupt the smooth progress of the
> NNTP documents then, in my view, that is what we should do.

You could always ask the authors what they think about it.  In
theory they could modify it in their "48" hours.  From my POV
it's a minor nit, and the outcome does not necessarily affect
what we do in USEFOR.
                      Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Jun 2005 11:54:41 GMT

>"header content" occurs three times.

You need to count the occurrences in USEPRO and USEAGE too.

But "content" is a special case and needs redefining to suit the way it is
used in USEPRO. So it should be "header body" in USEFOR, if we retain the
"header" terminology (IMO we should retain it).

>defined in RFC 2822) that occurs in the header (as defined in RFC 2822))

It is used variously in various places (sometimes when speaking of the
individual lines after a header is folded). Therefore, it SHOULD NOT be
used, unless the context makes it absolutely clear what is intended.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Jun 2005 11:56:39 GMT

>1. RFC 2822 isn't just "mail". This has been discussed before.

And your particular interpretation of it has been dismissed on each
occasion.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Jun 2005 17:09:54 -0400

> used, unless the context makes it absolutely clear what is intended.

I propose that we define "header line" explicitly as the part of a header 
(field) that starts at the start of a line and ends with CRLF.
That's the interpretation that seems consistent with its usage in USEFOR.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 17:46:30 -0400

> privately about insulting participants.

On list, so others can see what this is about, and for the record, the
previous warning was for use of the word "nonsense":

  Calling other people's statements "nonsense" is not going to help us get 
  these documents finished.

I have, before and since, seen others use the exact word, indeed the
phrase "utter nonsense" has been used by several WG participants on
several occasions, before and since.  I of course have no idea what
other private warnings might have been issued, and I can only hope
that all participants are being held to the same standard.

> the working group who do not agree with you

I can assure you that there was no such intent; the text quoted below
(retained verbatim) was in direct response to your statement in response
to Forrest's remarks which you quoted.  It was intended specifically to
address the striking differences between the draft under discussion and
other IETF work products, by way of an analogy.

And I would add that I intentionally ignored certain remarks in the
message to which I was responding which:
1. could be construed as an ad-hominem attack
2. would be as true with a number of other names substituted
and
3. added nothing to the substantive matters under discussion.

That message is of course part of the WG archive:
http://www.imc.org/ietf-usefor/mail-archive/msg01052.html

> - as well as being just vague  

It was, as the context below clearly shows, a direct response to a
particular statement, not a specific reference to specific text.

> > Which is basically what that draft says (except it's not nearly as honest

Your response appeared within minutes of my message.  In more than a week
since, I have seen at least three messages other than this one expressing
surprise and wondering specifically what the perceived problem is:

http://www.imc.org/ietf-usefor/mail-archive/msg01059.html
http://www.imc.org/ietf-usefor/mail-archive/msg01075.html
http://www.imc.org/ietf-usefor/mail-archive/msg01077.html

That makes at least four of us who are unsure what the specific problem is.

More troubling is that the substantive matters in the remaining (unquoted)
part of the article appear, as far as I can tell, to remain unaddressed
more than a week later.  Specifically, those issues include:

1. Have criteria for determining consensus changed, and if so, what are
   the new criteria?  This issue had been raised earlier by other WG
   participants.

2. Issues related to ensuring that WG consensus, once determined, is
   accurately reflected in the documents, permanently (or at least until
   some new issue warrants the Chair reopening a discussion).

3. Ground rules for discussion of specific principles and/or text.

4. A very specific suggestion for a specific "actionable item" as defined
   in the earlier message to which it was a response.

5. One example of earlier WG discussion and seven distinct points in
   response to a specific request to make a case for use of standard
   terminology.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 22 Jun 2005 01:47:27 +0200

Bruce Lilly wrote:
 
> On list, so others can see what this is about

Off list, because it's really nobody's business.

> I of course have no idea what other private
> warnings might have been issued, and I can only
> hope that all participants are being held to
> the same standard.

Okay, I can confirm this.  BTW, it was about a
somewhat dubious joke which could be understood
as an attack against you.  Are we now ready with
discussing private mails ?
                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 22 Jun 2005 02:09:53 +0200

So far for Re:mail and "off list" :-(

| When the "Reply-To:" field is present, it indicates the mailbox(es)
| to which the author of the message suggests that replies be sent.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 21 Jun 2005 21:48:53 -0400

On Tue June 21 2005 19:47, Frank Ellermann wrote:

> as an attack against you. 

I can state definitively that nothing I have said, on-list
or off-list, would have precipitated that.  I understand your
little jokes, but I can see how a newcomer or somebody
skimming the archives might not.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 21 Jun 2005 19:46:28 -0700

Well, as someone who used the utter nonsense phrasing recently, I
apologize to Charles and the other group participants for using language
that really wasn't constructive and was purely a voicing of frustration on
my part.  Harald's right -- it doesn't help us arrive at a conclusion.

I'll try to maintain a more even temper.  The temptation is to raise the
level of rhetoric when one feels like one isn't being listened to, in an
effort to make more impact, but that really isn't the relevant problem at
the moment.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 28 Jun 2005 21:59:49 +0200

In <[email-masked]>
Harald wrote...

| So far, no tickets have been opened on USEPRO.

...therefore I test this procedure now, what do we expect
from x2news gateways trying to inject articles with an 
"unfoldable" subject or similar header field body line ?

> should we just offer a way to force compatibility with
> our rules by adding a "dummy" word in the 1st line of
> the Subject ?

Read "1st line of a folded subject header field body" if
that's your preferred style.
 
> Subject: =?utf-8?Q?=EF=BF=BE?=

That's a dummy BOM if I got it right.  Ugly like hell but
better than silently rejecting "unfoldable" articles.  It
could be also (ab)used to enforce a non-empty subject. 

> what should the poor mail2news gateway do ?  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 29 Jun 2005 14:18:32 GMT

>"unfoldable" subject or similar header field body line ?

The current USEPRO text requires the gateway to produice a valid Netnews
article, somehow or other.

I would leave it to the gateway implementor to decide for himself how to
do this. We do provide some pointers in cases which could lead to severe
interoperability, looping, etc, but I do not think empty Subjects come
into that category (indeed, they will probably propagate perfectly well,
modulo a few sites which insist on removing trailing whitespace, followed
by sites which actively test for the required SP after each colon).

Does anyone know of a current mail2news gateway which actually goes to the
trouble of testing for this particular case?