headers
Charles Lindsey | 1 Jul 2002 11:57
Picon
Picon

Re: ietf-nntp Where are we at?

In <yl7kkjs8h9.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>What's improper about trying and seeing if you get a 503 response?  What
>problem are you trying to solve?

Because it's messy to have to invent a test case just to find whether some
feature is supported. I am thinking of the case where the client has a
large list of things it wants to query using HDR, and needs to use a
different strategy depending on whether the server supports that
particular header in its HDR. It has three choices:

1. Start off its big loop on the assumption that the header works. Oops!
we got a 503. Abandon the loop, initialize everything to do it the other
way, and start over.

2. Before starting on the big loop, generate an artificial test case just
to see whether that header is supported.

3. Use LIST EXTENSION to see whether that header is supported.

Yes, they can all be made to work but, as a writer of the client software
I know which facility I would prefer to use.

We invented the LIST EXTENSION command precisely so that clients could
plan ahead which strategies to use. It is there. Why not use it? It's not
as if it would be difficult for the server to provide.

--

-- 
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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Russ Allbery | 1 Jul 2002 18:53
Picon
Favicon
Gravatar

Re: ietf-nntp Where are we at?

Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

> Because it's messy to have to invent a test case just to find whether
> some feature is supported. I am thinking of the case where the client
> has a large list of things it wants to query using HDR,

I have a hard time imagining this scenario.  After you want more than a
few headers, it's quicker and more efficient to just download the article
headers with HEAD and do it yourself.  It's certainly preferred by the
news server administrator in most cases.

> We invented the LIST EXTENSION command precisely so that clients could
> plan ahead which strategies to use. It is there. Why not use it?

Because it's very complicated to specify this information in that format,
and involves potentially listing dozens of headers as arguments to the
extension, all for something that's likely to be almost never used since
for all normal operations just trying it and seeing if you get 503 is
easier and requires less parsing.

If this is the best reason available, I think I'm opposed.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
(Continue reading)

Permalink | Reply | 7 comments |
headers
Clive D.W. Feather | 2 Jul 2002 13:10

Re: ietf-nntp HDR replacement text

Russ Allbery said:
> 9.5.3  The HDR Extension

>   If the header occurs in a given article multiple times, only the value
>   of the first occurrence is returned by HDR.

Is that too prescriptive ? Would it be better to say "only the value of one
of the occurrences is returned" ?

>   If the requested header is present
>   but empty in a given article, a line for that article is included in the
>   output but the header content portion of the line is empty.  If the
>   requested header is not present in a given article, no line for that
>   article is given in the output.

Is that consistent with other commands ? I seem to recall that we decided
that OVER would treat no such header and empty header as equivalent.

>   If the optional argument is an
>   article number and no article with that number exists in the current
>   group, a 423 error response shall be returned.

I don't think this is the right thing to do. Consider:

    HDR subject 12345
    HDR subject 12345-12345

Shouldn't these always return the same thing ? If there's no article 12345,
what will/should the latter do ? Compare it to:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Clive D.W. Feather | 2 Jul 2002 13:27

Re: ietf-nntp HDR replacement text

Russ Allbery said:
> 9.5.3  The HDR Extension

Here are some proposed changes to allow metadata.

I think it's important that HDR, OVER, and LIST OVERVIEW.FMT are consistent
about the metadata they provide. Therefore descriptions of what metadata
there is belongs somewhere else, not here.

>   The HDR command retrieves specific headers from a specified range of
>   articles in the currently selected group or an article specified by
>   message-id.
> 
>   The required header parameter is the name of a header (e.g. "subject")
>   in an article and is case-insensitive.

Break paragraph here and replace the above text by:

  The HDR command retrieves specific headers from a specified range of
  articles in the currently selected group or an article specified by
  message-id. It can also return certain metadata about the article(s).
  The required header parameter is the name of a header (e.g. "subject")
  in an article, or the name of a metadata item, and is case-insensitive.
  Names of metadata items always include a colon.

  Except where stated otherwise, metadata items are treated as if they
  were header values, and references to headers in this description
  apply equally to metadata items.

[Given that last paragraph, the changed marked "[OPT]" could be left out,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clive D.W. Feather | 2 Jul 2002 13:52

Re: ietf-nntp Where are we at?

Stan O. Barber said:
> 027 with the additional comment that OVER and LIST OVERVIEW.FMT both must be
> implemented if either is.
> I would also note that some wording on how to clarify the whole issue of
> LIST and its relatives would be welcome. There
> was the suggestion that some wording might help, but I didn't see any.

We already have:

     Note that 
     where a command has variants depending on a keyword (e.g.
     LIST ACTIVE and LIST NEWSGROUPS), then 501 MUST be used when
     the requested variant is not implemented but the base command
     is.

However, perhaps you could add the following to 4, after the paragraph
ending "Arguments MUST NOT exceed 497 octets".

    Commands may have variants, using a second keyword immediately
    after the first to indicate which variant is required. The only
    such commands in this specification are LIST and MODE.

and in 4.1 make the edit:

    ... A server MAY provide
    extensions to this memo, including new commands,
+   new variants or features
    of existing commands, and other ways of changing the internal
    state of the server.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 2 Jul 2002 13:57

Re: ietf-nntp Where are we at?

Stan O. Barber said:
> Okey, I have reviewed all the items on your web site. Here are the ones I
> think are ok without discussion:
[...]

Of the remainder, could you please explain your position ?

024 - appears to be simple corrections.
028 - changing a response of HDR from 221 to 225
031 - the client should always be prepared for any generic response
032 - reordering commands
033 - assorted minor edits
036 - 503 response

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 2 comments |
headers
Clive D.W. Feather | 2 Jul 2002 14:00

Re: ietf-nntp Where are we at?

Russ Allbery said:
> Clive, could you please send the current version of your OVER text to the
> list?  I think there was some additional discussion since the last time it
> was posted.

Will do. I'll check my email logs for issues before sending.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 2 Jul 2002 14:57

ietf-nntp OVER extension

Okay, here's new text. I've been through my mail and applied all the issues
I can find.

NNTP proposed text
9.5.2 The OVER Extension
Last changed 2002-07-02 13:00 UTC

There was a suggestion that OVER could take a message-ID. This would need
to be optional; to allow it, include the lines prefixed with $, while to
forbid it exclude those lines.

After further thought, I've decided that it's better to include a generic
metadata description, even if it isn't used very much.

[I'm not sure where this first bit best fits.]

  X.X Article metadata

  Some commands in this memo refer to "article metadata". This is
  data about articles that does not occur within the article itself.
  Each metadata item has a name, which must include at least one colon
  other than at the end. Note that a historical feature of the
  LIST OVERVIEW.FMT command means that metadata names SHOULD NOT end
  with ":full".

  When generating a metadata item, the server MUST compute it for itself
  and not trust any related value provided in the article. [In particular,
  a Lines: or Bytes: header in the article MUST NOT be assumed to specify
  the correct value.]
(Continue reading)

Permalink | Reply | 32 comments |
headers
Russ Allbery | 2 Jul 2002 18:21
Picon
Favicon
Gravatar

Re: ietf-nntp HDR replacement text

Clive D W Feather <clive <at> demon.net> writes:
> Russ Allbery said:

>> 9.5.3  The HDR Extension

>>   If the header occurs in a given article multiple times, only the value
>>   of the first occurrence is returned by HDR.

> Is that too prescriptive ? Would it be better to say "only the value of
> one of the occurrences is returned" ?

My preference is to fully specify the protocol rather than leaving
anything undefined, but I could be convinced that's a bad idea for some
reason.  NNTP to date has preserved header order, however, and I think
it's good to encourage software authors to continue to do so as it may be
potentially useful for things like header signing.  And a fully specified
protocol is always nicer when possible.

>>   If the requested header is present but empty in a given article, a
>>   line for that article is included in the output but the header
>>   content portion of the line is empty.  If the requested header is not
>>   present in a given article, no line for that article is given in the
>>   output.

> Is that consistent with other commands ? I seem to recall that we
> decided that OVER would treat no such header and empty header as
> equivalent.

I'm not sure there's much else to be consistent with.  The difficulty with
OVER is that there's no real way of indicating an empty header; HDR has a
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 2 Jul 2002 21:20
Picon
Picon

Re: ietf-nntp Where are we at?

In <ylvg7zv18h.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>I have a hard time imagining this scenario.  After you want more than a
>few headers, it's quicker and more efficient to just download the article
>headers with HEAD and do it yourself.  It's certainly preferred by the
>news server administrator in most cases.

It is not likely that you will want to examine many headers, but you may
want to examine some particular header for a very large number of
articles. For example, you are filtering against some particular spam or
hipcrime flood and you have discovered that there is some feature in some
obscure header that positivley identifies the target articles. You would
prefer to use a HDR command rather than download headers for all articles
in the group.

>> We invented the LIST EXTENSION command precisely so that clients could
>> plan ahead which strategies to use. It is there. Why not use it?

>Because it's very complicated to specify this information in that format,
>and involves potentially listing dozens of headers as arguments to the
>extension, all for something that's likely to be almost never used since
>for all normal operations just trying it and seeing if you get 503 is
>easier and requires less parsing.

My proposal is not limited to the particular syntax I gave. Even if you
limit the possible parameters to the two common cases of "all" and
"overview" you will get most of the benefit.

But specifying the parameter is no burden on the implementor because, for
any given server, it is just a constant string that the implementor has to
(Continue reading)

Permalink | Reply | 6 comments |

Gmane