Subject: Tally from USEFOR Last Call on draft-ietf-usefor-usefor-08

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Jun 2006 07:40:38 -0700

The USEFOR WG Last Call on draft-ietf-usefor-usefor-08 has concluded. 9
people responded; I've attempted a summary of positions below.
If anyone thinks I've misrepresented their position, or if I've failed
to include anyone's position in the tally, please speak up on the list ASAP.

The following results are recorded:

- A clear consensus exists that there are issues that should be fixed
before publication (6 of 9)
- Two people believe that we should give up the effort

The specific issues raised are recorded in #1298, #1299 and #1300.
We'll split out details into separate issues when appropriate.

- An almost even split (5 against 4) exists between those who believe
we should send this document forward to the IESG and those who disagree
with that notion. Of those who disagree, 2 believe we should give up; 2
believe that we should keep the document in the WG and continue.

Details, with names:

1) Is draft-ietf-usefor-usefor-08 ready to go forward?

A - I believe it is ready to go forward.

  Dan Schlitt

B - I believe issues must be fixed; all my issues have been raised by
others, and once these are resolved, I believe it is ready.

  Ken Murchison
  Graham Drabble
  Harald Alvestrand
  Alexey Melnikov

C - I believe issues must be fixed; the following issue has not been
raised so far: .....................

  Charles Lindsey - #1298 (although he believes that he can survive
without fixing the issues)
  Richard Clayton - #1299

D - I have another opinion, which is: ...................

  Forrest J. Cavalier III - weblogs are more interesting
  Ralph Babel - give up (specific issues recorded in #1300)

2) How should draft-ietf-usefor-usefor-08 be carried forward?

A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call
and processing (knowing that it will likely be in REF hold at the RFC
Editor until draft-ietf-usefor-usepro is finished)

   Dan Schlitt
   Ken Murchison
   Graham Drabble (with procedural reservations)
   Harald Alvestrand
   Alexey Melnikov

B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state",
where we will promise to only change it if work on USEPRO proves to us
that we have something wrong in -usefor-.

   Charles Lindsey

C - I have another opinion, which is........

   Forrest J. Cavalier III ("B .... my real vote is to decharter")
   Ralph Babel - give up ("I vote for B - under protest")
   Richard Clayton ("B, but frozen conceptually, not frozen textually")

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 16 Jun 2006 17:58:05 GMT

>  Ralph Babel - give up (specific issues recorded in #1300)

I have already responded in detail to these. Many of them were reasonable
fixes for textual matters, and I indicated (with OK or similar wording)
that I was happy with them. If that is the general opinion, and Ken is
happy to accept those, then can we take those items as resolved?

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.

-- 
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: Fri, 16 Jun 2006 17:09:47 GMT

>without fixing the issues)

I see that Harald has reproduced the whole of my list, although Ken had
already agreed to incorporate all my minor corrections in the draft, so I
has presumed they were non-controversial and accepted.

So to confine discussion to the ones that Ken did not feel able to accept
without further guidance, I have reproduced below the ones that are still
outstanding, together with further comments (including some quotes from
various subsequent messages).

I have labelled my sub-issues as #1298.A, B, C, D, E and F, for
convenience of reference. The ones I am most concerned about are A and B.
C and E fix problems (bugs?) inadvertently introduced by Dan Kohn's
revisions. The rest are relatively minor, and none of them is a matter of
Life and Death.

Issue 1298.A
------------

> 3.1.5.  Newsgroups
> 
>    Not all servers support [FWS] in the list of newsgroups.  In
>    particular, folding the Newsgroups header field over several lines
>    has been shown to harm propagation significantly.  [FWS] in the
>    <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
> 
> No, that paragraph gives entirely the wrong impression, and I have
> repeatedly asked for it to be changed. What is wanted is something like:
> 
>    Current practice does [OR the current standards do] not allow [FWS] in
>    the list of newsgroups and thus it (and particularly folding) would
>    harm propagation significantly. Therefore, [FWS] in the
>    <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
> 
> Eventually I hope (for some value of "eventually") it will be allowed
> freely (since it is a confounded nuisance and current MUAs either do not
> display the whole line, or display it folded in inappropriate manners).
> But, for now, "SHOULD NOT be generated" is correct.

To which ALexey replied:

>>Personally I don't think that the suggested text is an improvement over 
>>existing one.

And I replied to him:

>My problem with the existing one is that it gives the impression that
>someone has tried an experiment to see if these things propagated, found
>that they didn't, and concluded that existing servers were therefore
>deficient.
> 
>This is not so. I doubt anyone has actually tried because it was well
>known that the code of INN, CNews, etc just did not support the feature,
>because RFC 1036 allowed neither whitespace nor folding in there.
>Son-of-1036 did not require it either (though it did give a warning that
>this was likely to change someday and suggested allowing it).
> 
>The [FWS] here is a new feature we have introduced ("someday" has
>arrived), as is clear from Appendix B. So why can't we have a wording that
>makes the true sutuation clear?
> 
>Now that I want to make too big an issue of this, because we could get by
>with the present wording is that's what the WG wants.

Issue 1298.B
------------

> 3.1.6.  Path
> 
> We still need some explanation for the presence of <diag-deprecated>. In
> response to your request, I proposed the folowing NOTE:
> 
>       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>).

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.
> 
> Also, I think, s/SHOULD/MUST/. 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.

I had some private email from Alexey on this, asking:

>>Clarifying question: are you talking about the first SHOULD, the second 
>>(SHOULD NOT) or both?

To which I replied
 
>I think it is the second (SHOULD NOT). It is not the end of the world if the 
>injecting agent puts a slightly wrong date-time there (though he "SHOULD" get 
>it right), but our drafts have always made it clear that altering what the 
>poster has written is always a MUST NOT (with only some very obscure 
>exceptions, like the moderator who sits on it for too long as in USEPRO 7.8).
> 
>This was one of Dan Kohn's rewrites, and I don't think we spotted the anomaly 
>he had introduced. Mind you, it is only a NOTE.

Issue 1298.D
------------

> 3.2.14.  Injection-Info
> 
> But also, with the demise of the sender <paramter> we have lost that "Joe
> Q. Public" example, which is a pity. How about:
> 
>       mail-complaints-to=
>         "\"Re: msg <[email-masked]>\" <[email-masked]>"
> 
> 
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-".

That was another Dan Kohn change which introduced an anomaly that we
didn't spot at the time.

Issue 1298.F
------------

> 3.3.  Obsolete Header Fields
> 
> The text which follows is copied verbatim from Son-of-1036. Assuming
> Son-of-1036 is to be republished an an information/historic RFC, ths could
 
Is there any chance of this happening?  Has any work been done on it?
 
> be shortened (I have removed all the long verbatim extracts from
> Son-of-1036 from USEPRO).
> 
> 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 for further details of
> what these headers formerly signified. ALso, the two sentences about "for
> hsitorical purposes" could probably be combined.

Ralph Babel also mentioned this (but wanted to omit more).

I think we should proceed on the assumption that Henry Spencer will indeed
fulfil his promise to republish Son-of-1036 as an informational/historic
RFC, and hence we should not include any large quotes from s-o-1036 (I
havge already removed all such large quotes from USEPRO).

We might have to beat him about the head during the RFC Editor phase, but
his willingness to do the job has never been in doubt and it is merely a
matter of obtaining sufficient Round Tuits.

Issue 1298.G
------------

 6.  IANA Considerations
> 
>       Header field name: User-Agent
>       Applicable protocol: netnews
>       Status: standard
>       Author/change controller: IETF
>       Specification document(s): This document (Section 3.2.13)
> 
> I would like to add
>       Applicable protocol: email
> 
> That is technically outside our charter, but was always intended and
> should be non-controversial. Could we ask the IESG for permission to do
> that?`

Well that is a pretty long shot, so I am not really expecting it to get
anywhere. WHen we are all done, I might introduce an I.D. to make this
header the official version of User-Agent in email too, just to get it
recorded in the IANA registry.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Jun 2006 03:03:19 -0700

I've gone through your list of "remaining issues" and created tickets 
for those that I think may warrant further tracking. For those where I 
don't think they warrant further tracking, I've given the reason below.

Comments from the WG welcome - if you want to address the two identified 
issues, please use that ticket number in the subject; if you want to 
comment on what's left here, use #1298 in the subject.

Thank you!

                     Harald

> revisions. The rest are relatively minor, and none of them is a matter of
As I said on the list, you performed the experiment yourself a year ago.
I won't reopen #1042. Rejected.

> Issue 1298.B
This is already a NOTE-rich paragraph, and I don't see any big harm in 
adding another.

I've made this ticket #1305.
> Issue 1298.C
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.

I've made this ticket #1306.
> Issue 1298.D
Grumble. Making the examples as complex as possible doesn't seem like a 
big benefit to me.
Anyone else who likes this?

> Issue 1298.E
I don't see the conflict. SHOULD NOT, and if you violate the SHOULD NOT, 
you MUST do this.

I don't see that the new text is clearer. Does anyone else like this?
> Issue 1298.F
No reply....
> matter of obtaining sufficient Round Tuits.
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.

Unless someone else speaks up in favour of this, I'll declare that this 
won't happen.
> Issue 1298.G

You're right. #1078 is closed, and will remain so.