Subject: [NNTP] Status and issue resolutions

From: Russ Allbery <[email-masked]>
Date: Wed, 18 May 2005 19:22:40 -0700

I've reviewed all of the recent traffic to the list.  I'm very sorry about
the delay in doing so.

The internationalization section looks good to me except for some minor
changes that I sent separately.  That means that we now need to publish
and go to Last Call.

Ken, can you put out final versions of your drafts?  I don't believe there
have been many changes, but I seem to recall that the latest versions
weren't fully published as I-Ds.

For the outstanding issues, let me recap:

 * LISTGROUP is now part of READER.
 * The range argument to LISTGROUP is in.
 * NEWNEWS is its own capability.

After reading the discussion about the return status from LISTGROUP and
making the argument to GROUP optional, I think we're finely balanced on
the merits of both.  I'm therefore going to make a decision that isn't
going to make anyone entirely happy, but which has a time-honored
tradition in getting software out the door:  I'm going to just say it's
too late to change anything else.

That means that the LISTGROUP response is the same as the GROUP response,
as has been in our draft for a while, and it needs to include the group
name.  However, the change to GROUP to allow the group to be omitted is
out, and the text should be reverted to the previous version when the
group name is mandatory.

I'm doing this in the interest of getting this draft out the door, and the
most easily defensible position for me is to say that we're just not going
to change the stuff that we've had in there for a long time at this point.

If you want to talk me out of this, you have two days.  I would like to
get all of the drafts published as I-Ds this weekend and then go to IETF
Last Call.  Clive, I believe the outstanding changes to pre-2 are
therefore:

 * Changing the GROUP text.
 * Updates to the internationalization section as mentioned in my previous
   message, if you're comfortable with those.
 * Inclusion of the changes from previous RFCs section as discussed, if
   you're comfortable with that section.

Will it be possible for you do make those changes and submit the I-D by
this weekend?  If this is a bad time, very much understood; just let me
know what a better final date would be.

I'm going to send a separate message in a moment with pointers to the
requirements for I-Ds for Last Call.  We need to go over them one more
time and make sure everything is good.  This is something that we can
parallelize, and the more eyes the better, so I'd greatly appreciate it if
other working group members could volunteer to go through those
requirements and post any needed changes or issues to the list so that the
work doesn't all fall on the editors and myself (particularly since I'm
struggling a lot lately to find free time).

I think we're basically done.  Let's push them out the door; our documents
are a vast improvement over the existing situation, and it will be much,
much easier to prepare future revisions based on the new documents.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 19 May 2005 12:01:39 +0100

>  * NEWNEWS is its own capability.

All done to the current text.

> If you want to talk me out of this, you have two days.

Given that LISTGROUP remains unchanged, there is no technical issue with
the change to GROUP. The issue is purely one of whether we should make the
change at this late date. Does that affect your opinion?

> I would like to

Done. Note that there are consequential changes to LISTGROUP (because its
behaviour is less like GROUP than before).

It is easy enough to change it back if I have persuaded you :-).

>    message, if you're comfortable with those.

I've left it as it was yesterday; I think you were happy enough with that
text.

>    you're comfortable with that section.

Done - see previous message.

> this weekend?

Yes, it should be.

> struggling a lot lately to find free time).

I've put a pre-3 draft in the usual place:

    <http://www.davros.org/nntp-texts/draft26.pre-3.txt>
    <http://www.davros.org/nntp-texts/draft26.pre-3.html>
    <http://www.davros.org/nntp-texts/draft26.pre-3.unpg.txt>

(the last of these has no page breaks, and may be easier for comparisons;
unfortunately this facility has only just become available).

Please use these, rather than anything else, for making the checks Russ
refers to and for checking formatting issues.

The formal draft-26 will go to the I-D editor no earlier than 15:00 UTC
tomorrow (Friday) unless I get a stop command from Russ or I spot a
show-stopper myself, so that's your deadline. It may well not be until the
weekend, but it *will* go before Monday morning.

> much easier to prepare future revisions based on the new documents.

Amen.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 May 2005 08:02:11 -0400

> weren't fully published as I-Ds.

No problem.  I've had them ready since last week (idnits compliant) and 
I've just been waiting for draft-26 since I refer to its ABNF 
constructs, among other things.  I can submit them anytime, and I can do 
it today or tomorrow afternoon to coincide with Clive's submission.  Let 
me know what you'd like me to do.

FYI, here are the changes that I have made.  If I've missed anything 
please let me know.

AUTHINFO:

      Changed:
      o  Updated to RFC 3978/3979 boilerplate.
      o  Uses new ABNF tokens from [NNTP].
      o  Fixed a typo in note regarding AUTHINFO SASL and 480 response.

STARTTLS:

      Changed:
      o  Updated to RFC 3978/3979 boilerplate.
      o  Fixed CAPABILITIES responses (specifically LIST arguments) in
         examples.

      Clarified:
      o  2.1: STARTTLS MUST NOT be advertised once a TLS layer is active
         or after successful authentication.

STREAMING:

      Changed:
      o  Updated to RFC 3978/3979 boilerplate.
      o  Uses new ABNF tokens from [NNTP].
      o  Uses new "multi-line data block" term from [NNTP].
      o  POST has its own capability.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Thu, 19 May 2005 19:50:07 -0700

Clive D W Feather <[email-masked]> writes:

> the change to GROUP. The issue is purely one of whether we should make
> the change at this late date. Does that affect your opinion?

I realize, and that has affected my opinion insofar as I was seriously
considering it.  However, the combination of the really late date and the
lack of consensus (including strong objections from at least one WG
participant) is enough for me to say let's not do this.

Should we suddenly develop a consensus that this change is fine,
particularly given that LISTGROUP's 211 response will continue to match
GROUP's, that would change my mind.  Other than that, I'd want to see a
really strong argument for why we have to have this, and the lack of
consensus worries me.

> Done. Note that there are consequential changes to LISTGROUP (because
> its behaviour is less like GROUP than before).

> It is easy enough to change it back if I have persuaded you :-).

:)

Note also the change in Appendix D.

> unfortunately this facility has only just become available).

Thanks!  I'm going to start writing my sheparding writeups either tonight
or tomorrow morning, as I expect that's going to take me a while to get
through.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 19 May 2005 19:51:18 -0700

> me know what you'd like me to do.

I don't see any reason not to go ahead and submit them.  No one has had
comments on them for a while, and I don't expect any sudden last-minute
discoveries before tomorrow.

> FYI, here are the changes that I have made.  If I've missed anything

Looks good to me.

Thanks!

---

From: Ade Lovett <[email-masked]>
Date: Fri, 20 May 2005 00:27:05 -0700

On May 19, 2005, at 19:50 , Russ Allbery wrote:
> GROUP's, that would change my mind.

Having read and re-read both the proposed changes, the relevant  
sections of code in a number of news server packages, and spoken to a  
number of people intimate with the workings of the more common  
newsreaders, I remove my objections to the proposed changes to  
LISTGROUP.

To be absolutely clear, I have no issues with the usage text as  
defined in section 6.1.2.1 of http://www.davros.org/nntp-texts/ 
draft26.pre-3.html#listgroup

My concerns with making the "group" argument optional to GROUP  
remain, however.  I don't believe this buys anything -- indeed, if  
time were permitting, I would give serious consideration to  
completely reworking GROUP/LISTGROUP -- the two commands are similar  
yet subtly different I cannot help but feel this will come back to  
bite us in the future.

-aDe

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 20 May 2005 08:36:31 +0100

> newsreaders, I remove my objections to the proposed changes to  

I'm glad to hear that.

> yet subtly different I cannot help but feel this will come back to  

I'm wondering what you mean by "similar yet subtly different".

At present, the *intended* differences are:
* LISTGROUP generates a multiline block after the initial 211 response
  (nobody was comfortable, way back when, with using a different number);
* LISTGROUP has a second argument that affects the contents of that block;
* the first argument to LISTGROUP is optional (with the consequential
  possibility of a 412 response).

Any other difference is unintentional and I'd really like to know what you
think there is.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 20 May 2005 08:41:47 +0100

Russ Allbery said:
>> the change at this late date.
[...]
> the lack of

Okay.

> Note also the change in Appendix D.

Oops. Fixed.

There's one error which I'm surprised nobody has spotted; I bet the ID-nits
stuff doesn't spot it either, even though it's mechanically testable.
Thankfully the xml2rfc bug is being fixed, though I could hand-fix it if
necessary.

[Hint in rot-13: ybbx ng gur gnoyr bs pbagragf.]

---

From: Ade Lovett <[email-masked]>
Date: Fri, 20 May 2005 00:49:23 -0700

>   (nobody was comfortable, way back when, with using a different  

This is the bit I don't like.

Essentially there are now five different ways for a client to "enter"  
a newsgroup, getting different returned information:

     GROUP foo
     GROUP            (whilst in foo)
     LISTGROUP        (whilst in foo)
     LISTGROUP foo
     LISTGROUP foo low-high

This strikes me as conceptually wrong.  To my mind, done "right", the  
GROUP command would be marked as going-away, with LISTGROUP (perhaps  
even LIST GROUP [<name> [<range>]], though this would require  
extending LIST a little bit more) taking over completely.

There is also the issue now that a client needs to figure out whether  
the "211" returned is now merely a single-line response (from GROUP),  
or the start of a multi-line response (from LISTGROUP).  Such  
overloading feels somewhat unclean.

-aDe

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 20 May 2005 09:00:56 +0100

> This is the bit I don't like.

I agree. But, as I said, nobody (else) was happy with changing the
response code.

> This strikes me as conceptually wrong.

Agreed.

> To my mind, done "right", the  
> even LIST GROUP [<name> [<range>]],

<FX: cringe>

> though this would require  

Meanwhile I'm thinking that extending GROUP would be a better way to go.

If I were starting from scratch, I would have something like:

    ENTERGROUP (group|".") [range]]

where:
    "."  means the current group
    specifying a range produces multi-line output (with a different code)

Then:
    GROUP                   =   ENTERGROUP .
    GROUP foo               =   ENTERGROUP foo
    LISTGROUP               =   ENTERGROUP . 1-          ) but with a
    LISTGROUP foo           =   ENTERGROUP foo 1-        ) different
    LISTGROUP foo 234-567   =   ENTERGROUP foo 234-567   ) response code

Amen.

However, just to clear my worries, do you see any *unintended* differences
between the present two specifications?

---

From: Ade Lovett <[email-masked]>
Date: Fri, 20 May 2005 01:06:08 -0700

>     ENTERGROUP (group|".") [range]]

I do believe that this something of this form should be strongly  
considered as one of the first officially sanctioned capabilities  
extensions after the release of this document.  We may have to live  
with the GROUP/LISTGROUP mess for now, but there's no reason it needs  
to stay that way.  In fact, the additions to both GROUP and LISTGROUP  
here should make it easy for both server- and client-side authors to  
add this on.

> between the present two specifications?

Not as far as I can tell, no.

-aDe