Subject: Re: #1298 -> 1305, 1306 + rejections and calls for comment (Re: Issue #1298 - Charles' niggles)

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Jun 2006 14:19:26 GMT

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>Charles Lindsey wrote:
>> In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>> Issue 1298.A
>> ------------
>>
>>> 3.1.5.  Newsgroups
>>>
>As I said on the list, you performed the experiment yourself a year ago.
>I won't reopen #1042. Rejected.

The purpose of the experiment was to determine whether the
non-implementation of [FWS], known to be prevalent up to that time
(because no standard had ever required it) had perhaps begun to lift a
little. It hadn't.

I won't push the issue any further, but my protest remains.

>>
>>
>> Issue 1298.B
>> ------------
>>
>>   
>>> 3.1.6.  Path
>>>
>>>       NOTE: Although , <IPv4address>es have occasionally been used in
>>>       the past (usually with a diagnostic intent), their continued use
>>>       is deprecated (though it is still acceptable in the form of the
>>>       <diag-deprecated>).
>>>     
>>
>>   
>This is already a NOTE-rich paragraph, and I don't see any big harm in 
>adding another.

>I've made this ticket #1305.

I am in favour (naturally), and it seems that you are at least unopposed.

>> Issue 1298.C
>> ------------
>>
>>   
>>> 3.2.1.  Injection-Date
>>>
>>>       NOTE: Since clocks on various agents may not be synchronized, the
>>>       <date-time> in this header field may not be later than the Date
>>>       header field, as would be expected.  Agents SHOULD use the <date-
>>>       time> they believe is correct when adding Inject-Info but SHOULD
>>>       NOT alter the pre-existing Date header field.
>>>
I think s/SHOULD NOT/MUST NOT/. There is one obscure situation (see USEPRO
7.8) where a moderator may rewrite the Date, but then I don't think a
moderator is an "agent" as we have defined the term.
>>>     
>The 07 version of the NOTE was:

>     NOTE: The <date-time> in this header field would normally be
>      expected to be later than the <date-time> in the Date header
>      field, but differences between the clocks on the various agents
>      and other special circumstances might vitiate that; no provision
>      is made for any such discrepancy to be corrected - better that the
>      news server should just insert the correct time as it sees it.

>I think the 08 version is a lot clearer in what it says, but introduces 
>protocol requirements where -07 was clearly just commentary.

Yes it is clearer, but it is bad practice to use RFC 2119 language in
NOTEs except where it is merely reinforcing normative material written
elsewhere. In this case, the "SHOULD NOT" is contrary to the general "MUST
NOT alter what is already present", as written at many places into USEPRO.
I would have no problewm with MUST NOT here.

>I've made this ticket #1306.
>>  
>>
>> Issue 1298.D
>> ------------
>>
>>   
>>> 3.2.14.  Injection-Info
>>>
>>>       mail-complaints-to=
>>>         "\"Re: msg <[email-masked]>\" <[email-masked]>"
>>>
>>>
>>>     
>Grumble. Making the examples as complex as possible doesn't seem like a 
>big benefit to me.

It was originally Frank Ellerman's example in the form of

	sender="\"Joe Q. Public\" <[email-masked]"

designed to show the complexities of quotes within quotes. It's no big
deal whether it goes in or not.

BTW, where is Frank these days?

>Anyone else who likes this?

>> Issue 1298.E
>> ------------
>>
>>   
>>> 3.2.14.  Injection-Info
>>>
>>>    Other <attribute>s SHOULD NOT be used unless defined in extensions to
>>>    this standard.  If non-standards-based <attribute>s are used, they
>>>    MUST begin with an "x-".
>>>
>>> That MUST conflicts with the SHOULD. How about:
>>>
>>>    Other <attribute>s MUST NOT be used unless defined in extensions to
>>>    this standard, or unless they begin with an "x-".
>>>     
>I don't see the conflict. SHOULD NOT, and if you violate the SHOULD NOT, 
>you MUST do this.

It has introduced, by implication, "SHOULD NOT use attributes starting
with "x-", which was not the intention. In -07 it was an implicit "MAY do
it" (with a proviso that it was for cases where the existing ones were
unsuited to your particular situation). My sentence is shorter, and
retains the -07 intent.

>>
>> Issue 1298.F
>> ------------
>>
>>   
>>> 3.3.  Obsolete Header Fields
>>>
>>> So I would suggest omitting the two paragraphs starting with:
>>>
>>>    Relay-Version contained ...
>>> and
>>>    Also-Control indicated ...
>>>
>>> and replacing them with a pointer to Son-of-1036...
>>   
>Introducing a dependency on son-of-1036 at this time would be extremely 
>unwise, in my opinion; the harm in including these two paragraphs is 
>minimal.

It does not introduce any dependency. The reference to Son-of-1036 would
be informative only (the paragraphs in question were merely explaining some
history). But I won't press the point.

-- 
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: Frank Ellermann <[email-masked]>
Date: Wed, 12 Jul 2006 04:08:33 +0200

Charles Lindsey wrote:

> designed to show the complexities of quotes within quotes.
> It's no big deal whether it goes in or not.

> BTW, where is Frank these days?

Spent some time on Mediawiki.  "No big deal" for putting quoted
text into quoted text in an example is okay.  With 108 unread
messages here I might miss some detail, I hope nobody's going
to use %22 instead of \" for this case.

> The reference to Son-of-1036 would be informative only (the
> paragraphs in question were merely explaining some history)
> But I won't press the point.

If USEFOR sits in the RFC editor queue waiting for USEPRO, and
s-o-1036 makes it in time, this nit could be trimmed in the
final AUTH48 clean up.

Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2006 21:03:57 +0100

Charles Lindsey wrote:

>There were other items that I did not accept for various reasons. May I
>suggest to Ralph that he produces a list of the ones that he still wants
>to be considered, as I have just done in the case of my own list.
>  
>
Ralph didn't produce a list. So I've created the following tickets:

1309 USEFOR 3.2.7 - Distribution header field needs more description

1310 USEFOR 3.2.9 - Approved header field description

1311 USEFOR 3.2.12 - Default value for the Archive header field 
(copyright issue)

1312 USEFOR 3.3.1 - Description of Lines header field can be much shorter

1313 USEFOR 2.2 - syntax for Usenet Articles: RFC 2822 + MIME

1314 USEFOR 3.1.5 - Definition of Newsgroups header field is not precise

1315 USEFOR - definition of "poster"

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2006 21:05:09 +0100

> 1315 USEFOR - definition of "poster"

I've also reopened 1156: USEFOR Appendix: IANA registration forms for 
headers

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Jul 2006 21:59:30 +0100

3 more tickets:

1334 USEFOR: Path preloading and Path components case sensitivity

1335 USEFOR: description of Injection-Date purpose is not precise

1336 USEFOR 3.2.4: Additional description of Expires header field

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Jul 2006 18:34:38 +0100

>>I've made this ticket #1306.
I've seen nobody objecting to this change.
Ken applied the proposed text, so the ticket is now closed.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 25 Jul 2006 12:03:54 GMT

>Ken applied the proposed text, so the ticket is now closed.

Which proposed text? If you mean with the "MUST NOT", then fine.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Jul 2006 17:44:19 +0100

>Which proposed text? If you mean with the "MUST NOT", then fine.
Yes.