[ietf-nntp] :bytes metadata

[Ken Murchison]

Clive D.W. Feather wrote:

> We currently say:
> 
>     It MUST equal the number of octets in the entire article - headers,
>     body, and separating empty line - except that each CRLF pair MAY
>     (but SHOULD NOT) be counted as a single octet.
> 
> Andrew from Supernews pointed out the following additional issues:
> 
> (1) In a cluster system, the number of octets in the article may vary
> between cluster members (e.g. because folding happened differently or
> because they have different Path: headers).
> 
> (2) Should dot-stuffing be counted?
> 
> (3) Should the final '.' CRLF be counted?
> 
> In other words, do we see :bytes as indicating the size of the article in
> "canonical" form, or the number of octets that will come down the line in
> response to ARTICLE?
> 
> My inclination is to say that the answers to (2) and (3) are "no"; the
> value is a storage octet count rather than a wire octet count.

Exactly.  Dot stuffing and the final '.' are related to how the content 
gets tranferred, NOT the content itself.  If an implementation decides 
to store articles in wire-format, they MUST NOT include the extra '.'s 
in the calculation.

> I'm not sure what to do about (1). I can think of four possible fixes:
> (A) Say that the value applies to the current session and note that, while
>     it SHOULD be constant across sessions, there are cases when it isn't.
> (B) Require :bytes to be a maximum in cluster cases; is this practical?
> (C) Allow it to be one, two, or three values:
>         actual
>         actual,max
>         min,actual,max
> (D) Have another metadata item reporting the potential problems with the
>     value.

I'd say (A).  A cluster is a specific implementation and we shouldn't 
munge the protocol to account for idiosyncrasies specific to them.

IMO all members of a cluster should be configured and perform 
identically, whether it be article canonicalization/storage or article 
expiration, which would make this a non-issue.  All members of a cluster 
should present a unified via of the newsspool, a client shouldn't have 
to deal with cluster specific junk.  You couldn't get away with this in 
an IMAP cluster.

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