ietf-nntp Re: draft-ietf-nntpext-streaming-00.txt

[Jeffrey M. Vinocur]

On Fri, 6 Jun 2003, Clive D.W. Feather wrote:

> Okay, a first pass through this.

Thanks!


> We took the leading spaces out of LIST EXTENSIONS.

Whoops, fixed.


> I would actually remove the whole of section 2 and replace it with the
> formal stuff required by section 8 of the base document.

I've added near the end an IANA considerations section since -00 was
published, actually.  I'm looking at section 8 now, and it doesn't seem to
prescribe a particular format, although I'm open to suggestions.  Can you
be more precise about what you're suggesting?

(I do want to discuss the extension-label and descriptive text further, 
we'll get to that in a minute.)


> Do existing implementations actually return STREAMING to LIST EXTENSIONS?
> If not, and this is an invention on your part, can we change the name to
> something more specific, like "pipelineable posting commands" and
> "PIPEPOST".

I've only looked at INN, and innd does not presently support LIST
EXTENSIONS at all (nnrpd does, of course).  A quick glance at one of my 
peers running Diablo indicates that it also doesn't support LIST 
EXTENSIONS.

So yes, we can change it to anything you like.  I wonder if "pipelineable
feeding commands" and "PIPEFEED" might be more clear, though, since "post" 
has a dual meaning (any client->server article transfer, and the POST 
command in particular).

(Anybody with a suggestion that doesn't involve the word "pipelineable"?)


> I'm not clear what's going on with MODE STREAM. I take it it's a command
> like MODE READER that possibly changes internal state. In which case, I
> suggest you copy the entirety of the MODE READER section and then edit it
> to describe the actual situation.

I have no idea what's going on with MODE STREAM either.  I'll raise this 
in a separate thread.


> Don't include generic responses, including 480, in the tables of responses.

Yeah, I meant to ask for comments about that.  (I included them since 2980 
did, but felt kinda bad doing so.)  Fixed.


> You should make it clear that, while a 438 from CHECK means TAKETHIS is
> likely to be a waste of effort, it's not illegal.
>
> Make it clear that the message-id in the responses MUST be that in the
> initial command.

Both good points, fixed.

 
> Don't put that "[the entire article ...]" bit in the syntax, put it in
> the description; look how I address the same issue for POST.

Gotcha.


> Can I suggest that we say a server MAY respond with 431 or 438 to a
> TAKETHIS command, [...]

Interesting thought, I'll address it in the next message as well.


> Private question: are you hand-editing to match my style or using xml2rfc?
> If the latter, do you want to use my tools as well?

I'm using nroff, actually, because that's how Chris sent me the drafts of
the other documents I'm working on.  It works pretty well for these
smaller documents (that is, I've thought about switching but it seems like
a lot of effort that I'd rather spend on other things as long as the
output is acceptable to everyone).

Next time I start a document from scratch, I'd definitely be interssted in
using your tools, though.

-- 
Jeffrey M. Vinocur
jeff at litech.org