Subject: Style of documentation (Re: #1043 "header": Suggested resolution)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 01 Jul 2005 13:13:43 +0200

Forrest,

somewhat flippantly, I'll assign half a point to Charles and half a point 
to you.

Most of the readers of the document will not bother to read all the 
supporting documentation in detail.
But - most of those readers are NOT implementors They seek a general 
understanding, or want to clarify a particular point, they don't need to 
understand all of it fully. And even more - most of the time, those readers 
who ARE implementors can be well served by the "surface meaning" of the 
words, and they will have little reason to dig into the references 
(normative or not).

Only in SOME cases will people have reason to dig into the documents to 
clarify *exactly* what is meant by some point or prohibition.
And it's our job as standards writers to make sure that in *those* cases, 
the path back is clear.

                    Harald

--On torsdag, juni 30, 2005 17:58:48 -0400 "Forrest J. Cavalier III" 
<[email-masked]> wrote:

> Charles Lindsey wrote:
>
>> In <[email-masked]> "Forrest J. Cavalier III"
>> <[email-masked]> writes:
>>
>>
>>> Charles Lindsey wrote:
>>>
>>>> I pointed out that in the real world implementors and other readers DO
>>>> take shortcute when reading documents. That is a fact of life. You
>>>> have to live with it.
>>
>>
>>> No I do not have to live with it.  As has been said so many times: we
>>> need a clear, complete, unambiguous specification that is as easy to
>>> read as possible, BUT WE HAVE NO CONCERN for people who refuse to read
>>> and understand NORMATIVE references.  We can totally ignore such people
>>> when writing, because they are irrelevant.
>>
>>
>> To describe a substantial part of your audience as "irrelevant" is no way
>> to write any document, whether technical or otherwise.
>>
>> If that is your attitude, then we will just have to agree to differ.
>>
> No, we don't have to agree to differ on this either.
>
> I request the chairs issue a clear statement that we will use RFC2119
> imperatives and when used we expect ALL implementors to understand them as
> defined in RFC2119.  We will also expect them to understand English.
>
> I request the chairs issue a clear statement that we expect all
> implementors
> claiming conformance are expected to read and understand NORMATIVE
> references.
> (I thought we already had that declaration of the obvious, but guess
> not...)
>
> I request the chairs issue a clear statement that we will repeat and
> highlight
> text from NORMATIVE references only when we have reason to believe that
> our
> draft text is so difficult to write clearly that it is likely to mislead
> an implementor into violating a normative reference.
>
>

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 01 Jul 2005 09:41:11 -0400

> somewhat flippantly, I'll assign half a point to Charles and half a point 

I didn't think we were competing.  If you think that you need to assign
Charles a half point to keep him happy, we have a big problem.

There is no "agreeing to differ" on the makeup of our audience.  It is
a matter of decision, not opinion, and all WG participants must agree
to cooperate to write for that audience.
I agree with reuse and multi-purposing and even "suface reading", but
not for standards work.  Standards have no need to be written for
careless people.

If Joe Usenet User wants to read a specification written for implementors,
WE HAVE NO CONCERN FOR HIM.  Let someone else paraphrase and write
"USEFOR for dummies."

People who do "surface reading" are not implementors who can claim
conformance.  I thought it was self-evident.

Look, this isn't an excuse to be less clear and less verbose, it is
the only way to be more concise and more clear.  It is the only way
to finish, and avoid the "paraphrased meaning mismatch" problems
recently discussed.

Maybe some concrete examples are in order.

1. USEFOR-USEFOR 3.2.1 has this text, which is unnecessary if you
assume implementors can read, or necessary if you assume they
are lazy.  Which is it?
    See the remarks under Section 3.1.2  regarding the syntax of date-
    time and the requirements and recommendations to which it is subject.

2. See also 3.2.4 (Expires)

3. USEFOR-USEFOR 3.1.6 has this text,
     The Path header indicates the route taken by an article since its
     injection into the Netnews system.

That's fine and enough for USEFOR, but we seem to be writing for
people who do not understand a simple statement, so we beat them
over the head with more.....
                                        Each agent that processes an
    article is required to prepend one (or more) identities to this
    header.  This is primarily to enable relaying agents to avoid sending
    articles to sites already known to have them, in particular the site
    they came from, and additionally to permit tracing the route articles
    take in moving over the network, and for gathering Usenet statistics.

All of that will just repeat some text from USEPRO or USEAGE, and
we have to assume implementors can read those documents.

But there is more! later on it is RESTATED AGAIN!
    Each <path-identity> in the <path-list> (excluding the one in the
    <tail-entry>) indicates, from right to left, the successive agents
    through which the article has passed.

And not content with deferring construction to USEPRO, we get yet another
reference to USEPRO
    The full procedure for constructing a Path header
    as well as the specific format and use of <path-identity> and <tail-
    entry> are discussed in [USEPRO].

4. We have a lot of ABNF repeats of RFC2822.  Why?  E.g. in 3.1.1 we
    have

      from            =  "From:" SP mailbox-list CRLF

    My point is that who can understand that without reading RFC2822 for
    "mailbox-list"?  And if implementors have to read RFC2822, then they
    have to read RFC2822 which has the ABNF already.

    Sure, you may argue that a "surface reader" wants the ABNF in USEFOR,
    but there is a cost.

    The problem of "subtle differences" in ABNF terms
    has already been raised.  If we state ABNF in USEFOR-USEFOR, then careful
    implementors will be forced to COMPARE the ABNF in USEFOR-USEFOR with
    what is in RFC2822, instead of saying "OK, my RFC2822 code for From will
    be fine."

    Not only that, but sometimes we are the same, and sometimes not.  (E.g.
    Message-ID....I also think there is a big problem in redoing all the
    Message-ID ABNF instead of restricting the ABNF that is in 2822 already.)

USEPRO is way worse, but not a subject we are allowed to discuss yet.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 02 Jul 2005 06:48:00 +0200

Forrest J. Cavalier III wrote:
 
> If Joe Usenet User wants to read a specification written for
> implementors, WE HAVE NO CONCERN FOR HIM.

1 - I'm Joe Usenet User and want to understand the spec. - no
    problem with some prerequisites and keeping it as short as
    possible, but it must make sense where it differs from any
    plausible expectation (especially 1036, s-o-1036, 2822)
  
2 - the spec. is not only for implementors, it's also for news
    admins, gateway operators, moderators, and cases like (1) 
    
> Let someone else paraphrase and write "USEFOR for dummies."

3 - Yes, this "someone" also has to get the drift of the spec.

> this isn't an excuse to be less clear and less verbose, it is
> the only way to be more concise and more clear.

Concise and clear is fine, but not beyond recognition.

>     Each <path-identity> in the <path-list> (excluding the
>     one in the <tail-entry>) indicates, from right to left,
[...]

Yes, that could be simplified, besides it's now wrong, we have
separated <path-identity> and <tail-entry>, and excluding the
latter makes no more sense.  

But it's perfectly okay to say that this beast was once a bang-
path, otherwise "not-for-mail" would be gibberish.  The reader,
implementor or not, can be 15 years old, and (s)he has a right
to know absolutely nothing about Usenet in the past millennium.

> We have a lot of ABNF repeats of RFC2822.  Why?  E.g. in
> 3.1.1 we have

>       from            =  "From:" SP mailbox-list CRLF

Just compare it with 2822, it is *different*, and that's why we
have to show the modified syntax.
                                  Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 3 Jul 2005 08:01:32 -0400

[...]
> The reader,

RFC 2822: April, 2001 = this millenium
The others: "the reader, implementer or not..."
 
> have to show the modified syntax.

No, we have no authority to modify RFC 2822 or what it defines.
Attempting to do so by redefining syntax will confuse readers
(implementers or not).  It provides no clue as to *why* there is
a difference or which of the two conflicting specifications has
precedence (unlike 1036, which clearly deferred to 822 in the case
of conflict).  We can provide an implementation note such as:

Note: Some poorly designed but widely implemented software, Foo Bar,
  crashes and burns if an optional space is not present after the
  colon delimiting the field name from the field body.  Therefore,
  generators of messages which are also news articles SHOULD include
  a space after the colon.   Software which cannot handle lack of an
  optional space, an HTAB rather than space, etc., SHOULD be upgraded
  as soon as practicable.

Keeping the syntax as it is defined in the normative reference, i.e.
general, and dealing with specific issues n implementations notes
provides clarity for readers (implementers or not).  It explains clearly
*what* issue exists, *how* to work around that issue, *where* and
*when* to do so, *who* should do so, and it introduces no grammar
inconsistencies.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 03 Jul 2005 19:43:25 +0200

> RFC 2822: April, 2001 = this millenium

Really "nn", I used to get this wrong.

>> we have to show the modified syntax.
> we have no authority to modify RFC 2822

Nobody proposed "updates 2822", just stick to the plan
as defined in the Charter, anything that's required in
NetNews and a proper subset of 2822 is simply REQUIRED.

> poorly designed but widely implemented software, Foo Bar,
> crashes and burns if an optional space is not present after
> the colon delimiting the field name from the field body.

Optional is not the same as required.  I tested SP => FWS,
and it's not good enough.  Let alone SP => [CFWS] to get
pure 2822.

I have not yet tested to replace the dubious SP [FWS] by
1*WSP allowing at least HT where folding clearly does not
work.  IIRC somebody (Charles, Henry, Russ, or maybe all)
said that HT doesn't work.

And I tried to replace the erroneous SP [FWS] by a correct
SP *WSP, nobody but Charles cared, and he didn't like it.
Check the old SP [FWS] and [FWS] CRLF thread - apparently
that's left to a hot *WSP fix in the IETF last call.  Bye.

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 3 Jul 2005 14:31:51 -0400

On Sun July 3 2005 13:43, Frank Ellermann wrote:
> Nobody proposed "updates 2822",

2822 defines the From field (among others) and its syntax.  If
you introduce a different syntax for the same thing, you are
either trying to alter that syntax or you are introducing a
conflict (in this case with a normative reference).  Best to
keep the ABNF grammar as defined in 2822, and introduce notes
restricting usage of the full syntax where necessary or
recommended.

> Optional is not the same as required.

It's not required by the normative reference.  Or its
predecessor.  Or that specification's predecessor...
s/an optional space /a space character/ if it makes you happy.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 03 Jul 2005 12:17:20 -0700

Bruce Lilly <[email-masked]> writes:

> conflict (in this case with a normative reference).

We're trying to reuse portions of a normative reference while overriding
other portions.  It's not a particularly difficult or unusual concept, and
it should be immediately familiar to anyone who's done object-oriented
programming.

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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 03 Jul 2005 21:44:45 +0200

Bruce Lilly wrote:

> If you introduce a different syntax for the same thing

We're not "introducing" a single bit apart from Injection-Info
and backwards compatible (modulo IPv6 colon) Path improvements.

What we do is to describe the things as they are.  And they are
different from RFC 2822.  Handwaving, weasel words, and wishful
thinking to pretend equality are no option.  It's our job to
describe the differences.  And this mandatoy SP _is_ different.

> Best to keep the ABNF grammar as defined in 2822, and
> introduce notes restricting usage of the full syntax where
> necessary or recommended.

If you think that saying [FWS] in places where folding is not
allowed by not less than a MUST NOT is okay we disagree - I'd
prefer to say *WSP instead of lying in syntax.

Some days ago you complained about a 2822 obs-MUST that is a
MAY in USEFOR, with two exceptions where it's again a MUST.
What about all those funny [FWS] that are in fact only *WSP ?

Sorry Bruce, I haven't invented this SP *WSP stuff.  But it
doesn't go away by lying in the syntax, and [FWS] is certainly
not better.  FWS could be nice, but without a time machine we
have no way to "introduce a different syntax" in news or mail:

"Each header line consists of a keyword, a colon, a blank, and
 some additional information.  This is a subset of the Internet
 standard, simplified to allow simpler software to handle it."

> It's not required by the normative reference

If you wish to discuss the WG Charter with Alexey and Harald
go ahead.  I have no serious problems with it, the additional
bit about a "proper subset" or "simplified" (claimed by 1036)
is clear.

Your maximal demands are counterproductive.  In the case of the
<id-right> semantics where you did not support my <id-domain>
what you'll get is exactly what you didn't want, Charles' idea
of (among others) a random case insensitive RHS.

It will be the same problem with the SP, instead of fixing the
bogus SP [FWS] we'll end up with a foul compromise of SP [FWS]
instead of the correct SP *WSP, no chance for a transition plan
to 1*WSP.  IMHO you make it worse with your maximal demands. :-(

                         Bye. Frank

P.S.:  The References are a case where 2822 indirectly allows
       [CFWS] [CFWS].  Our CFWS in the <msg-id-list> is better.

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 3 Jul 2005 18:28:04 -0400

> and backwards compatible (modulo IPv6 colon) Path improvements.

s/introduce/specify/

> describe the differences.  And this mandatoy SP _is_ different.

Fine, but don't try to redefine From, orig-date, zone, msg-id,
unstructured, etc.  One definition is OK; two conflicting
definitions will cause confusion.
 
> prefer to say *WSP instead of lying in syntax.

We need not and should not provide ABNF for grammar productions
defined in RFC 2822:

   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.
 
> What about all those funny [FWS] that are in fact only *WSP ?

One or more notes detailing the issue and the added restriction.
 
> of (among others) a random case insensitive RHS.

A redefinition of msg-id is going to cause problems, no matter
whose it is.
 
I suspect, based on comments made by Mark Crispin two years ago
here, that there will be a problem at Last Call.  Unless of course
we avoid the problem by not trying to contradict 2822.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 03 Jul 2005 15:49:15 -0700

> we avoid the problem by not trying to contradict 2822.

That's nice.  Mark objected to things in the NNTP standard too, and it's
been approved by the IESG.  Let's not get too worried about objections;
let's worry about getting it right.

We have to redefine message ID.  The version in RFC 2822 doesn't work on
Usenet.  Why are we even still discussing that question?

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 04 Jul 2005 03:07:27 +0200

Bruce Lilly wrote:

> I suspect, based on comments made by Mark Crispin two years
> ago here, that there will be a problem at Last Call.  Unless
> of course we avoid the problem by not trying to contradict
> 2822.

With that "unless" it couldn't fly.  Not that the IESG has any
problems to approve contradicting drafts intentionally, but as
you said there will be a proper "last call".  And a Message-ID
concept incompatible with RFC 977bis, 1036, s-o-1036, and 1738
would be too obvious.  All potential "last call" problems with
our fixed <msg-id> are limited to some objections against the
misleading <id-right> etc. production names, no big deal.  Bye

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 04 Jul 2005 08:44:03 -0400

> it should be immediately familiar to anyone who's done object-oriented

It is dishonest to imply that this is ever done by redefining the API (i.e. types
of function parameters and return values.).

The only sane way of overlaying an operational restriction in object-oriented
programming is to apply the restriction and then call the base class implementation.
It is NOT OK to re-implement it in the derived class.

Anyone who overrides a base class implementation by REPEATING and REWRITING
it is totally missing the point of reuse.

Now most people on this list are going to roll their eyes at this point and say
"no big deal -- we just get a bulkier implementation, no harm in that."

They are wrong.  You cannot write specified software or standards specifications
that way.

Although REPEATING text from normative references is often "merely" clutter,
REWRITING and PARAPHRASING text and ABNF from normative references is a big
problem:
    1. Already discussed the problem of subtle mismatches in understanding,
       leading to incompatible implementations.

    2. Different text (and especially different ABNF productions) precludes
       reuse.  If one could take off-the-shelf software that was already known to be
       RFC2822 compliant for processing "From", a different ABNF in USEFOR-USEFOR-04
       would require review of that software for compliance in all ways all over again.

       One ABNF production + restrictions allows review of software just for compliance
       with the restrictions.  That's a really obvious difference that all careful
       implementors already understand.

    3. All software requires validation and maintenance.  More software requires
       increases validation and maintaince.  Reuse is important.

Programmers who are happy operating at CMM level 1 or below shouldn't even be part of
writing a standard.

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 4 Jul 2005 10:07:27 -0400

On Sun July 3 2005 18:49, Russ Allbery wrote:
> Let's not get too worried about objections;

Assuming the objections are substantive -- and I have no reason to
believe otherwise -- there is little distinction; if we "get it right"
(i.e. clear with no conflicts with normative references and other
standards track protocols) there won't be any substantive objections
on those issues.
 
> We have to redefine message ID.

Whether you're referring to the Message-ID field or to the msg-id field
component,  you'll have to do more than simply assert "we have to
redefine"...

> The version in RFC 2822 doesn't work on 
> Usenet.

The field or the component?  Can a subset of what is permitted by the
RFC 2822 syntax work, or is an incompatible superset required?  If a
subset is OK, why -- specifically -- *must* we redefine rather than
apply specific additional restrictions via normative text?

> Why are we even still discussing that question? 

Because there is not yet a satisfactory resolution.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:08:48 GMT

>  optional space, an HTAB rather than space, etc., SHOULD be upgraded

No, there is no question of "SHOULD be upgraded as soon as practicable" as
regards that SP after the colon. We have agreed long ago that was a step
too far, and that decision is also now hard-coded into the
NNTP-standard-to-be which has just passed its IETF Last Call.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:08:48 GMT

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 4 Jul 2005 13:04:53 GMT

>And it's our job as standards writers to make sure that in *those* cases, 

Since I agree 100% with what you say, your half point is accepted with
gratitude.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jul 2005 11:19:57 -0700

> component, you'll have to do more than simply assert "we have to

We have.  At great length.  At this point, I'm going to assume that it can
be taken as a given, no matter what you say, and stop repeating myself.

> apply specific additional restrictions via normative text?

Because we actually want to help people write parsers rather than just
concern ourselves with theoretical acts of purity, which means that
producing an actual working ABNF that incorporates the required
restrictions is pretty useful.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jul 2005 11:33:51 -0700

Forrest J Cavalier <[email-masked]> writes:

> The only sane way of overlaying an operational restriction in
> object-oriented programming is to apply the restriction and then call
> the base class implementation.  It is NOT OK to re-implement it in the
> derived class.

This is way more absolute than is actually the case in practice.
Sometimes you want to use all of another object except one area that you
need to replace completely.  It's certainly not the preferred way of doing
things, but it can also be far cleaner (and require far less internal
knowledge of the parent class) to completely replace part of the
implementation rather than trying to selectively override things deep in
the internals.

Anyway, we may have reached the limit of utility for this particular
analogy, since standards are a lot more transparent to other documents
than object classes.

> Although REPEATING text from normative references is often "merely"
> clutter, REWRITING and PARAPHRASING text and ABNF from normative
> references is a big problem:

>        leading to incompatible implementations.

So be clear.  *shrug*.

>        reuse.  If one could take off-the-shelf software that was already
>        known to be RFC2822 compliant for processing "From", a different
>        ABNF in USEFOR-USEFOR-04 would require review of that software
>        for compliance in all ways all over again.

You have to review all of your generators.  That's the whole POINT.

For the parsers, that's where we make a statement that the reformulation
is a strict subset, and then we *stick* to that, and check that very
carefully, so that software authors can rely on that statement.  It may be
worth an RFC 1036-style statement that any place where we mess up and
don't make things a strict subset, people should treat it that way anyway,
but really, we should just get it right.

>     3. All software requires validation and maintenance.  More software
>        requires increases validation and maintaince.  Reuse is important.

Yes, yes, we all agree that it would be great if we could use RFC 2822
as-is.  Also, I'd like a pony.

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 4 Jul 2005 15:17:25 -0400

> Because we actually want to help people write parsers

If the differences result in a subset of RFC 2822 format, then there
already exist parsers: open source, closed source, validating,
non-validating, C, C++, Perl, Python, etc.  Many have been tested
extensively.

[non-sequitur snipped]
> which means that 

If you really mean a parser, see Forrest's points about testing and
reuse, as well as the above comments.  Indeed, the primary point of
changing from the incompatible A news format to one based on RFC 822
(as noted in RFCs 850 and 1036) was to take advantage of existing
tools.

If you mean a generator, ABNF might or might not help.  ABNF isn't
needed to use fprintf etc.; simple normative text saying "do X, don't
do Y" is likely to be more useful to somebody writing generator software.
I doubt that many authors of generation software are going to go
through the trouble to write a formal grammar-based parser in order
to be able to generate fields.  I know of exactly one implementation
that works that way, and in that case generation is an add-on bonus
to the primary function of parsing with validation.

In either case (generator or parser) Forrest is quite correct that
a conflicting ABNF resets the conformance testing odometer.  Now if
we were developing a new, incompatible format and accompanying
protocol, that wouldn't matter as there would be no base.  But we
are updating a specification for an existing, deployed format and
protocols, where there is a substantial base of software that may
need to be updated.

In the unlikely event that there were a necessity to define ABNF, for
crying out loud choose a different name for the different rule to
avoid conflict with 2822.  That seems common sense; if you were to
write a children's story about a pet rabbit having nothing to do
with whales or whaling, it wouldn't be a good idea to title it
"Moby Dick", as that would likely cause confusion (possibly among
other undesirable side-effects).

---

From: Russ Allbery <[email-masked]>
Date: Mon, 04 Jul 2005 12:24:51 -0700

> non-validating, C, C++, Perl, Python, etc.  Many have been tested

And are not suitable for use on Usenet in places where they need to block
the message IDs that are problematic.  If I'm going to write a message ID
parser for innd, I'm going to use the Usenet ABNF, not the mail ABNF and
then hack on additional scans for restrictions.

> If you mean a generator, ABNF might or might not help.

Thanks.  I've written enough parsers by now to know when it helps and when
it doesn't, but I appreciate your concern.

> In either case (generator or parser) Forrest is quite correct that a
> conflicting ABNF resets the conformance testing odometer.  Now if we
> were developing a new, incompatible format and accompanying protocol,
> that wouldn't matter as there would be no base.  But we are updating a
> specification for an existing, deployed format and protocols, where
> there is a substantial base of software that may need to be updated.

Currently, valid Usenet message IDs have no ABNF, so there's no odometer
to reset.

> avoid conflict with 2822.

As I've said multiple times, I don't care what the productions are called.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Jul 2005 05:28:50 +0200

Bruce Lilly wrote:

> Can a subset of what is permitted by the RFC 2822 syntax
> work, or is an incompatible superset required?

<id-local> "@" <id-domain> and Charles' <id-left> "@" <id-right>
are syntactically both subsets of 2822 <id-left> "@" <id-right>

Semantically Charles' version is apparently a superset, he
wants to allow any unique random <msg-id>.  And that includes
any intended or unintended abuse of foreign RHS name spaces.

My version is semantically like (2)822.  One minor point that
could be fixed if needed:  Charles allows <whatever@[}>, and
my version insists on a non-empty domain-literal.  Otherwise
they are syntactically equivalent and semantically different.

> Because there is not yet a satisfactory resolution.

Alexey and Harald proposed that it's clear.  IMHO that's not
correct, Charles' version is dangerous and confusing.  Bye.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 16:42:51 GMT

>any intended or unintended abuse of foreign RHS name spaces.

Eh? Which "Charles' version" is that? I have proposed various texts which
pick up on the RECOMMENDATION in RFC 2822 (though I think Harald's text is
something yet again). I have declined to go back to the slightly more
restrictive rule in RFC 822.

Abuse of other people's name spaces is not a matter for a format document,
but it could be a proper matter for USEAGE, and maybe even USEPRO (see my
text for path-identity).

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 5 Jul 2005 16:33:05 GMT

>It is NOT OK to re-implement it in the derived class.

Indeed that is good practice. In this case RFC 2822 is the base class. If
some message of the base class (a syntax rule in our case) is different in
the derived class (USEFOR) (e.g. because some [CFWS] has changed to a
mandatory SP), then you give the new rule. If the rule in the derived
class is the same as in the base class, then you do not repeat it.

But that is exactly what has been done in USEFOR, with no exception that I
can think of. So what is your problem? The object-oriented analogy seems
to work pretty well in this case.

>REWRITING and PARAPHRASING text and ABNF from normative references is a big

In such cases, the wording needs to be clear that what is written is not
normative.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Jul 2005 17:54:24 +0200

Charles Lindsey wrote:

>> And that includes any intended or unintended abuse of
>> foreign RHS name spaces.

> Eh? Which "Charles' version" is that?

There's only one "Charles' version", and that's where you said
that a "long random string with an @ in the middle" could be
okay if it follows the syntax.  It could be also my RHS, and
then it's not okay.  Or it could be one of the "@oemcomputer"
RHS, the latter is probably more realistic and more dangerous.

> I have declined to go back to the slightly more restrictive
> rule in RFC 822.

Or 1036, 1738, s-o-1036.  The restriction is necessary to make
it work for everybody, it's almost the same problem as for the
<path-identity> - we can't have too many "oemcomputer".  Bye

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 17:32:19 -0400

On Mon July 4 2005 09:08, Charles Lindsey wrote:
> too far

No, we haven't, as a review of the WG archives makes clear.

> , and that decision is also now hard-coded into the 

Nothing an NNTP draft could possibly say has any bearing on parsing
of the Internet Message Format, much less on whether or not such software
should be brought into conformance with the Internet Message Format
specification.