Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 10 Apr 2005 22:21:14 GMT

In <[email-masked]> "Dr John Stockton" <[email-masked]> writes:

>I've been reading
>http://www.ietf.org/internet-drafts/draft-ietf-usefor-useage-01.txt,
>March 2005.

>I don't think I'm qualified to address the mailing list of the Usenet
>Format Working Group;

If this group were confined to "qualified" people, there would be no group
:-).

I have copied your message to the group, and am CCing this reply to you,
but you will need to subscribe if you want to see any further responses.

>"1.2.  Objectives
>...
>         NOTE: The extreme irritation caused to other readers by such
>         violations is not to be underestimated; ..."

>And by false accusations of such violations!

Yes, but don`t let's over-egg the pudding :-) .

>"2.2.  Textual Notations
>...
>         NOTE: While such explanatory notes may seem superfluous in
>         principle, they often help the less-than-omniscient reader
>         understand the true intent of the specification in cases where
>         the wording is not entirely clear."

>The wording should always be entirely clear, in the opinion of the
>author!  But the meaning may well not be entirely obvious to such a
>reader.

Yes. It's a nice quote by Henry Spencer from Son-of-1036 - too good not to
use it.

>"3.1.  The Well-Behaved Posting Agent
>    The implementor of a posting agent SHOULD make it possible for a
>    suitably perseverent poster to generate any article, ..."

>I don't believe that "perseverent" is a real word, except maybe in the
>full OED; "perseverant" is in Chambers' Dictionary;

OK, I will follow Chambers.

>Last sentence of 3.1 contains "imppose".

Fixed.

>"3.1.1.  Construction of Headers
>...
>    Posting agents SHOULD permit the poster to include headers of
>    arbitrary length (and MUST permit at least 79 characters)."

>You must mean "header lines" or "characters per line" ?

No, I meant headers. The next sentence tells them to fold, preferably
before 79, but certainly before 998.

>...
>    "NOTE: ... standard 80-column screen"
>Since use of text-only screens is now rare, how about something more
>general, such as 80-column display, or viewport ?

OK, I now say "display".

>...
>    "... WSP ..."
>Undefined in useage-01;...

Defined in Usefor, by way of RFC 2822.

>"3.1.1.1.  Date
>...
>       Date: Sat, 26 May 2001 11:13:00 -0500 (EST)"

>To rub it in, you could observe (after checking) that EST is used in
>Australia, probably (+1000).

If someone can quote the Autralian rule authoritatively, and what "EST"
stands for there, I might even be tempted to do just that.

>I'd like to see full rigorous ISO 8601 dates being allowed, with day-of-
>week as an optional but recommended comment -
>       Date : 2001-05-26 11:13:00 -0500 (EST) (Sat)

It would be nice, but the email/news Date format is too entrenched to
change it now.

>In a time example, I'd choose an hour greater than 12, to expand the
>experience of US readers.

I think US readers are sufficiently familiar with the 24 hour clock as
seen in Date headers. But I have changed it anyway.

>"3.1.1.2.  From"

>Contains the word "ro".

Oops!

>    "NOTE: ..."

>ISTM that it might be better to bow to /force majeure/, and indicate,
>maybe by reference to another document, what is and what is not
>reasonable common practice.  In particular, that the form used, after
>removal of any ".invalid", MUST NOT be a possible address for someone
>else, present or reasonable future.

I am not sure. Sometimes people just add ".invalid" to their own genuine
address. Not always spammer proof, but most spammers are stupid (Rule #3,
or something) - I get massive amounts of spam directed at the Message-ID of
my articles from 3 years back. The main purpose of that sentence was to
encourage people NOT to munge their addresses WITHOUT adding .invalid as
well.

>"3.1.1.4.  Subject
>...
>    regognized" !

Oops!

>"3.1.1.7.  Organization
>...
>    ... unless ... and unless ... "

>ISTM that in English that's syntactically unreasonable!  "unless ... or
>... "?

No, I meant 'and'. Applying De Morgan's rule, I said "DIScouage UNLESS
acceptable AND UNLESS useful", which is the same as "ENcourage IF
acceptable OR useful" (or would be if there wasn't a possible middle to
exclude).

>"3.1.2.1.  Signatures
>    A "personal signature" is a short closing text automatically added"

>ISTM that it is not necessarily automatic.

OK. How about "added (usually automatically)"?

>Since sigs are not normally quoted, you *might* agree with the
>Implementors of Turnpike that sig lines can have as many as 79
>characters each.

See my own signature below :-) .

>"3.1.2.3.  Content-Transfer-Encoding
>...
>       moreover, Usenet articles are very likely to include trailing
>       whitespace in the form of a personal signature (3.1.2.1)."

>3.1.2.1 is clear that the signature follows, and does not include, the
>separator, which has a whitespace.

OK. 'in the form of the "-- " which introduces a personal signature'.

>"3.2.1.1.  Subject
>...
>    1. Although the "Re" (which is an abbreviation for the Latin "In re",
>       meaning "in the matter of", and not an abbreviation of "Reference"
>       as is sometimes erroneously supposed) may be understood by English
>       speakers, and indeed by speakers of most European Languages, its
>       use in a newsgroup where articles were customarily written in
>       Arabic, or Hindi, or Chinese would be less than helpful."

>That seems disrespectful to Eastern intelligence.  If they can manage to
>use News, they should be able to recognise the odd alien term (however
>displayed) occurring always in a specific context.

Apparently a lot or orientals are very unfamiliar with the Latin alphabet,
but nevertheless are beginning to use mail and even news in their own
languages. Granted they cannot avoid it 100% yet. There are domain-names
(even if puny-coded), local-parts and newsgroup-names and much else that
is still in ASCII, but those issues are being worked on (though slowly).

>"3.2.1.1.1.  Examples
>...
>    Software can always recognize
>    that such changes have occurred from the References header."

>I don't see that software can do that.  ISTM that what you mean is
>something different.

No. Every followup MUST have a References header, so if software sees a
References header it knows it is a followup (or something to be treated
like a followup). So it can adjust its display accordingly (e.g. by
threading); it does not need to see the "Re: ". From the software writer's
POV, "Re: " is just some awkward characters that he has to detect and
ignore in order to get his threading (well, some forms of threading) to
work properly.

>"3.2.1.3.  Mail-Copies-To

Has now been removed from all our drafts.

>If it is permissible for a mail article to contain a newsgroups line
>(I've seen it), then ISTM that a mail reading agent should give clear
>warning.

The intention is that the meaning of a Newsgroups header, if it is seen in
an email message, is to indicate that it was also posted to that newsgroup
(but replies to that email message should not include such a header unless
they are posted to the newsgroup as well).

>"3.2.1.4.  References
>...
>     carefully put their
>     by precursors.]"

>"there" !

Oops! But it was not in text that was meant to go into the final version.

>"3.2.2.1.  Quoting and Attributions
>...
>    SHOULD be so dintinguished ..." - distinguished.

Genuine Oops! that one.
>...
>    "   The followup agent SHOULD also precede the quoted content by an
>    "attribution line" (however, ..."

>I'd like to see a terminological amendment, to remove any taint of a
>suggestion that the attribution is a single physical line.

Point taken. s/"attribution line"/"attribution"/ and consequential changes
elsewhere.

>"  The attribution MAY contain also a single <newsgroup-name> (the one
>    from which the followup is being made), the precursor's message
>    identifier and/or the precursor's Date and Time."

>'single' .. usually; but it can be convenient to change that manually to
>indicate the degree of cross-posting.

Sure. You edit anything manually as you want. But nobody wants to see more
than one <newsgroup-name> in the attribution, and I have never seen a user
agent that put more than one (in fact they often don't put any).

>'Date and Time' - IMHO, the Zone of the date & time is needed and should
>be mentioned; and there should be consideration of whether this should
>be a direct copy of the original Date:, whether it may be translated
>into the responding poster's (or ISO) notation, whether it may be
>adjusted to GMT or responder's zone.  I do dislike being attributed as
>having written on such as 3/21/05, or during AM/PM.

I think normal practice is to use the same date-time format as in the Date
header. Does anyone know of a system that changes the zone from whatever
was actually in the Date header of the precursor? Basically, we are trying
to document current best practice here rather than invent anything new.

>"   o The various fields may be separated by arbitrary text "
>                                             ^ brief

OK. "arbitrary (but brief) text". Yes, we have all seen some horrors that
people have inserted in there, and there is not much we can do to stop
them. But no harm in giving a hint and hoping they take it :-( .

>"3.3.2.  Presentation of Articles
>3.3.2.1.  Threading

>    4. Construct a tree in " ...

>ISTM that it *might* be useful for a reading agent to display an
>indication, for example, of the difference in tree-depth between that
>article and the most previously read article in that thread, presumably
>as a signed number, possibly background-coloured for sign.  Of course,
>all reading-agents should make thread-structure capable of being fully
>seen; but it's not necessarily obvious when going from article to
>article.  Just a thought.

I think this is an area where newsreader implementors should be encouraged
to experiment. If you don't like what your newsreqder does, then you
should go out and buy a better one. I think the purpose of that whole
section was to point out various possibilities, each of which has
disadvantages if used on its own, and to encourage experimentation with
hybrids. There are some agents out there that seem to do a pretty good
job, and others that don't.

>"3.3.2.2.  Killfiles
>      Moreover, articles
>    crossposted to many newsgroups SHOULD be considered to have been read
>    once they have been seen in any of those groups."

>But "many" is not the right word, surely.  Cross-posting can be to 2
>groups, and 2 < a few < many.

s/many/several/

>"3.3.3.  Interpretation of Bodies
>...
>    Tab (US-ASCII 9) SHOULD be interpreted as sufficient horizontal white
>    space to reach the next of a set of fixed positions (customarily set
>    at every 8th character)."

>"... after every 8th character)."

OK.

>"4.1.  Construction of Headers
>    According to [USEPRO], an injecting agent MAY add other headers not
>    already provided by the poster, but SHOULD NOT alter, delete, or
>    reorder any existing header."

>It might be useful to attempt to post a copy of that to certain
>moderated newsgroups, sic, as comp.lang.asm.x86 :-( .  And, perhaps, to
>strengthen SHOULD NOT, if possible.

No. Moderation comes before injection. Usepro makes it clear that
moderators have some discretion to establish a "house style". In a
well-managed hierarchy, there will be charters and moderation rules and
means to enforce them. OTOH, some charters overdo it with pages and pages
of rules governing the moderation process (and you and I know which group
I am talking about :-( ). Our drafts need to stand well back from such
issues.

>"6.1.1.  The 'newgroup' and 'mvgroup' Control Messages"
>...

>And 'rmgroup' ????

Actually no. That section was concerned with the detailed contents of
newgroup etc messages, and rmgroup messages don't have any details - it's
all or nothing :-) .

>"9.2.  Construction of Bodies
>    Posters SHOULD avoid using control characters and escape sequences
>    except for tab (US-ASCII 9), formfeed (US-ASCII 12) and, possibly,
>    backspace (US-ASCII 8), for reasons already explained in section
>    3.3.3."

>I thought that CR & LF were control characters too.

Sure, but the requirements for CRLF are well documented in Usefor (via RFC
2822).

>"12.  Contact Address
>Editor
>         Charles. H. Lindsey"
>                ^ One wonders what the dot is for.

One does indeed!

>P.S. I have discovered that the document bears a non-functional E-mail
>address; sending the above to :-

>"        Email: [email-masked]"

>gave

>"A message that you sent could not be delivered to one or more of its
>recipients.

Ah! Manchester have finally pulled the plug on my old email address.

-- 
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: Seth Breidbart <[email-masked]>
Date: Sun, 10 Apr 2005 22:50:24 -0400 (EDT)

>>  In particular, that the form used, after removal of any
>>".invalid", MUST NOT be a possible address for someone else, present
>>or reasonable future.
>
> address.

That's why it says "someone _else_".

>>      Moreover, articles crossposted to many newsgroups SHOULD be
>>    considered to have been read once they have been seen in any of
>>    those groups."
>

How about "multiple"?

Seth

---

From: "Ruud H.G. van Tol" <[email-masked]>
Date: Mon, 11 Apr 2005 12:15:50 +0200

Seth Breidbart:
> Charles Lindsey:
>> Dr John Stockton:

>>> ".invalid", MUST NOT be a possible address for someone else, 
>>> present or reasonable future.

>> I am not sure. Sometimes people just add ".invalid" to their own
>> genuine address.

> That's why it says "someone _else_".

Same observation here. The "for" didn't emphasize the issue of 
ownership (or permission) though, so it was easy to read it 
otherwise, like the "someone else" being the spammert.

-- 
Grtz, Ruud

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Apr 2005 12:14:32 GMT

>How about "multiple"?

I think "several" is good enough. Anyone else preferring "multiple"?