headers
Russ Allbery | 26 Aug 2002 07:25
Picon
Favicon
Gravatar

Re: ietf-nntp HDR replacement text

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

>> Hm.  Good point.  Having it just return an empty result is consistent
>> with how XHDR is currently implemented in INN and also seems consistent
>> with XOVER.  It's *not* consistent with the OVER text currently in the
>> draft, however, which states:

>>     If no articles are in the range specified, the server returns a 420
>>     error response.

>> I prefer that all of your examples above do the same thing,

> So do I.

>> and that all of them return a 423 error code.

> Note that it makes little difference to the client - both an error code and
> an empty list are easy to detect.

This is true.

I don't think we've yet reached any conclusions about this.  Could other
people please weigh in?  When all the articles in a specified range for
HDR or OVER are not present, should the server return an empty list, or an
error code?

Specifying an individual number and specifying a range should result in
the same behavior.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 26 Aug 2002 07:30
Picon
Favicon
Gravatar

ietf-nntp Current HDR text

This is the current HDR text, reordered so that it matches the current
ordering of command descriptions in our draft.  I think it's suitable for
inclusion; we can always iron out additional modifications later.

I haven't included any notes about metadata yet; see my other message.

I changed the description from the previous description to return article
numbers but no data for articles which are present but do not have the
header in question.  This is consistent with the existing behavior of XHDR
as pointed out by Andrew.  Unless there is a strong argument for breaking
with that tradition, I think it's best to stick with existing practice.
But I can be convinced otherwise.

I still also have the text with the other ordering, which I find somewhat
clearer.

9.5.3  The HDR Extension

  This extension provides one new command, HDR.  The label for this
  extension is HDR.

9.5.3.1  HDR

      HDR header
      HDR header range
      HDR header <message-id>

  The HDR command retrieves specific headers from a specified range of
  articles in the currently selected group or an article specified by
  message-id.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 26 Aug 2002 07:26
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

> 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.

Maybe it would be better to put that together as a separate proposal with
the accompanying changes to all of those commands?

I didn't include these changes in the current proposed HDR text yet
because as of yet there's no metadata to query, and once we start talking
about metadata I want to include real examples.

--

-- 
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
Permalink | Reply | 1 comment |
headers
Russ Allbery | 26 Aug 2002 07:32
Picon
Favicon
Gravatar

Re: ietf-nntp HDR replacement text

Russ Allbery <rra <at> Stanford.EDU> writes:

> Maybe it would be better to put that together as a separate proposal
> with the accompanying changes to all of those commands?

> I didn't include these changes in the current proposed HDR text yet
> because as of yet there's no metadata to query, and once we start
> talking about metadata I want to include real examples.

Ah, I see, you included that in your OVER proposal.  Okay, I'll go put in
those changes now (although I'd prefer something like :lines and :bytes as
the metadata tags rather than line:count because I think the leading
punctuation makes the metadata look more special).

--

-- 
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
Permalink | Reply | 0 comments |
headers
Russ Allbery | 26 Aug 2002 07:48
Picon
Favicon
Gravatar

Re: ietf-nntp OVER extension

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

> 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.

Why does this need to be optional?  It's a new command; we can require
that this be implemented.  I'm personally slightly inclined to require it,
but I think if it's not required, it should be omitted entirely.  Adding
an optional command is just too much more complexity.

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

>   X.X Article metadata

Sometime before all of the command descriptions, I think.  Probably the
section immediately before it, which would put it around the same place as
the description of wildmat.  That makes sense to me.

>   This memo defines two metadata items: "line:count" and "byte:count".

I'd like to see :lines and :bytes here instead.

>   9.5.2 The OVER Extension

>   This extension provides two commands, OVER and LIST OVERVIEW.FMT. The
>   label for this extension is OVER. If the extension is implemented then
>   both commands MUST be provided.

I think we should drop the LIST OVERVIEW.FMT command.  As discussed on
(Continue reading)

Permalink | Reply | 11 comments |
headers
Russ Allbery | 26 Aug 2002 07:52
Picon
Favicon
Gravatar

Re: ietf-nntp OVER extension

Clive D W Feather <clive <at> demon.net> writes:
> Charles Lindsey said:

>> >  For the five mandatory headers, the content of each field MUST be
>> >  based on the original header with the header name and following colon
>> >  and space removed. If the article does not contain that header, or if
>>        ^^^^^
>>        whitespace
>> 
>> Is that right? There might be several spaces plus the odd TAB.

> I thought that existing practice was to remove just the first space. Can
> others comment here ?

I believe it should only remove the first space after the colon, but
existing practice in INN is to remove all leading whitespace.  I think
that only removing the first space makes considerably more sense, though,
since the first space is part of the article format but the remainder of
the line is part of the actual header.  I think we should correct this as
part of the standardization process, the same way we're correcting
handling of non-printing characters (without exactly following any
existing implementation).

--

-- 
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 | 2 comments |
headers
Russ Allbery | 26 Aug 2002 07:53
Picon
Favicon
Gravatar

ietf-nntp New HDR text (with metadata)

9.5.3  The HDR Extension

  This extension provides one new command, HDR.  The label for this
  extension is HDR.

9.5.3.1  HDR

      HDR header
      HDR header range
      HDR header <message-id>

  The HDR command retrieves specific headers from an article or 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 or articles.  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.

  The range parameter of the second form of the HDR command may be any of
  the following:

   * an article number
   * an article number followed by a dash to indicate all following
   * an article number followed by a dash followed by another article
     number.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Maurizio Codogno | 26 Aug 2002 09:49
Picon
Gravatar

RE: ietf-nntp New HDR text (with metadata)

>  The header content is in all cases taken from the article.  This means
>  that, for example, a request for the header "Lines" returns the contents
>  of the "Lines" header of the specified articles, if any, not the line
>  count metadata or any other server-generated value.

This would mean that a person adding ad-hoc headers in her articles could
foul the server asking for metadata. Is it advisable?

ciao, .mau.

_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 3 comments |
headers
Robert Schuettler | 26 Aug 2002 14:18
Picon
Picon

ietf-nntp Discussion of draft-dfncis-netnews-admin-sys-04.txt

Hello everyone,

we have put together a new "working" version of our NAS draft trying to
address the points discussed here. Please have a look and tell us what
you think:

http://nas.cis.fu-berlin.de/draft/draft-dfncis-netnews-admin-sys-05.txt

---8<-------------------------------------------------------------------

Overview - Main Changes:

[6.3.3]

The definitions for "hierarchy-name" and "newsgroup-name" were
identical, so now it is simply "name".

[6.3.3.7 LSTR]

We have removed the reference to INN wildmat patterns.  The use of "*"
as a wildcard is allowed once following the (beginning of) a hierarchy
name. This means that the only commands using patterns in this protocol
level are things like: LSTR bln* , LSTR bln.* , LSTR b*

[6.3.3.8/9 HIER and DATA]

The term "range" describing the data fields that are requested was
replaced by "selection". The specification of "selection" now follows
the list if requested hierarchies instead of preceding it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Allbery | 26 Aug 2002 17:54
Picon
Favicon
Gravatar

Re: ietf-nntp New HDR text (with metadata)

Maurizio Codogno <puntomaupunto <at> tin.it> writes:

>>  The header content is in all cases taken from the article.  This means
>>  that, for example, a request for the header "Lines" returns the contents
>>  of the "Lines" header of the specified articles, if any, not the line
>>  count metadata or any other server-generated value.

> This would mean that a person adding ad-hoc headers in her articles could
> foul the server asking for metadata. Is it advisable?

The underlying theory of the metadata headers is that they would contain a
colon somewhere in the name, such as line:count or :lines, which makes it
impossible for them to conflict with any regular header in the article.

--

-- 
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
Permalink | Reply | 2 comments |

Gmane