Internet-Drafts | 2 Feb 2004 22:07
Picon
Favicon

I-D ACTION:draft-ietf-nntpext-streaming-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NNTP Extensions Working Group of the IETF.

	Title		: NNTP Extension for Streaming Feeds
	Author(s)	: J. Vinocur
	Filename	: draft-ietf-nntpext-streaming-01.txt
	Pages		: 9
	Date		: 2004-2-2
	
This memo defines an extension to the Network News Transport
Protocol [NNTP] to provide asynchronous transfer of articles.  This
allows servers to transfer articles to other servers with much
greater efficiency.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nntpext-streaming-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nntpext-streaming-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Clive D.W. Feather | 5 Feb 2004 10:31

Re: :bytes metadata

Russ Allbery said:
>> It seems to me that the most likely use for :bytes is to reserve space
>> to hold a copy of the article. For that, it's more important not to have
>> too small a number than too big a one.
> The only thing that it's used for in practice so far as I know is
> killfiling and rough size estimates.  Do you have any reason to believe
> that it's used for anything more important than that?

You don't think it's used for space allocation, as I suggested?

> I think we're putting too much effort into something that clients don't
> actually care about.

Perhaps. It feels wrong to me to have these under-specified features, given
that we've made changes from historical practice (calling it ":bytes", for
example). But it looks like I'm alone on this.

If you don't mind, I'll add a few words about what existing implementations
do, then call it a day:

   Note to client implementers: some existing servers return a value
   different to that above. The commonest reasons for this are:

   o  counting a CRLF pair as one octet;

   o  including the "." character used for byte-stuffing in the number;

   o  including the terminating "." CRLF in the number;

   o  using one copy of an article for counting the octets but then
(Continue reading)

Clive D.W. Feather | 5 Feb 2004 11:35

Draft 21

We've now (subject to comments on my :bytes text of an hour or so ago)
closed off all the issues on my list.

Do you want me to put a pre-release version on my web site for the group to
look at, or are we ready to have draft 21 published?

Then what? Does it now go to IETF, or is there another stage first?

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Ken Murchison | 5 Feb 2004 15:54

Re: :bytes metadata

Clive D.W. Feather wrote:

>> Perhaps. It feels wrong to me to have these under-specified features, given
> that we've made changes from historical practice (calling it ":bytes", for
> example). But it looks like I'm alone on this.

No, you're not alone.  I don't like having fuzzy specs either.  The 
problem is that the audience/participation on this list is really small, 
and seems to only contains server authors.  I think an issue like this 
needs to be fed to a larger audience, like the newsgroups, and hopefully 
we'll get some input from client authors.

--

-- 
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
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Ken Murchison | 5 Feb 2004 15:55

Re: Draft 21

Clive D.W. Feather wrote:

> We've now (subject to comments on my :bytes text of an hour or so ago)
> closed off all the issues on my list.
> 
> Do you want me to put a pre-release version on my web site for the group to
> look at, or are we ready to have draft 21 published?

I'd like to see a diff against -20 so it will be easy to see what has 
changed.

--

-- 
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
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

ned+ietf-nntp | 5 Feb 2004 15:59

Re: Draft 21

> We've now (subject to comments on my :bytes text of an hour or so ago)
> closed off all the issues on my list.

> Do you want me to put a pre-release version on my web site for the group to
> look at, or are we ready to have draft 21 published?

> Then what? Does it now go to IETF, or is there another stage first?

The way it usually works is that the chair requests a final two week
last call on the WG list. If that doesn't turn up anything the
WG chair then asks the area director for an IETF-wide last call. And then
the document goes to the IESG.

				Ned
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Charles Lindsey | 6 Feb 2004 12:30
Picon
Picon

Re: :bytes metadata

In <40225921.2020205 <at> oceana.com> Ken Murchison <ken <at> oceana.com> writes:

>Clive D.W. Feather wrote:

>>> Perhaps. It feels wrong to me to have these under-specified features, given
>> that we've made changes from historical practice (calling it ":bytes", for
>> example). But it looks like I'm alone on this.

>No, you're not alone.  I don't like having fuzzy specs either.  The 
>problem is that the audience/participation on this list is really small, 
>and seems to only contains server authors.  I think an issue like this 
>needs to be fed to a larger audience, like the newsgroups, and hopefully 
>we'll get some input from client authors.

Me2. I am unhappy that different servers can return different sizes for
the identical article. But I don't see an obvious way out.

--

-- 
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: chl <at> clerew.man.ac.uk      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
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Clive D.W. Feather | 10 Feb 2004 16:57

Re: :bytes metadata

Ken Murchison said:
> No, you're not alone.  I don't like having fuzzy specs either.  The 
> problem is that the audience/participation on this list is really small, 
> and seems to only contains server authors.  I think an issue like this 
> needs to be fed to a larger audience, like the newsgroups, and hopefully 
> we'll get some input from client authors.

Okay, I've posted to news.software.nntp.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Clive D.W. Feather | 11 Feb 2004 10:14

Re: Draft 21

Ken Murchison said:
>> Do you want me to put a pre-release version on my web site for the group to
>> look at, or are we ready to have draft 21 published?
> I'd like to see a diff against -20 so it will be easy to see what has 
> changed.

Okay, there's a pre-release of the draft at
<http://www.davros.org/nntp-texts/draft21.pre-1.txt> and
<http://www.davros.org/nntp-texts/draft21.pre-1.html>.

The former has diff-marks in it; they were hand-generated, so won't be
repeated in future.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp

Ken Murchison | 11 Feb 2004 15:26

Re: Draft 21

Clive D.W. Feather wrote:
> Okay, there's a pre-release of the draft at
> <http://www.davros.org/nntp-texts/draft21.pre-1.txt> and
> <http://www.davros.org/nntp-texts/draft21.pre-1.html>.
> 
> The former has diff-marks in it; they were hand-generated, so won't be
> repeated in future.

Thanks Clive.  I have a few comments/questions:

- How should LIST NEWSGROUPS handle a group which has no decsription? 
The language in the draft leads me to believe that if an empty response 
is given, that the client might infer that there are no groups 
available.  Is this correct?  I assumed that LIST [ACTIVE] is used to 
get a list of available groups and LIST NEWSGROUPS was just 
informational (it returns descriptions for those groups that have them). 
   Or does LIST NEWSGROUPS have to return a line (with possible empty 
description) for every groups that is returned by LIST ACTIVE?

- How should the HDR ALL capability interact with the new LIST HEADER 
MSGID?  The reason why I proposed HDR ALL was so that the server didn't 
have to list every possible header that it can fetch.  Now that we are 
allowing HDR to return different [sub]sets of header/metadata depending 
on the form of HDR, the simplicity of HDR ALL has gone away.  For 
example, how do we handle a server which can return all headers when 
fetched by msg#, but can only return metadata when fetched by msgid (or 
vice-versa)?  Using HDR ALL will be misleading, since is only applies to 
half of the cases.  Perhaps we should get rid of HDR ALL and replace it 
with a different response code (214, 216?) for LIST HEADERS which means 
"all".
(Continue reading)


Gmane