[ietf-nntp] :bytes metadata

[Andrew - Supernews]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 >> That's a substantial implementation overhead - an implementation
 >> that stores articles in wire format never has any need to compute
 >> or store the "canonical" size of the article.  There are three
 >> possible sizes of an article: the size as stored locally, the
 >> canonical size, and the wire-format size. There are two common
 >> cases:

 Ken> Again, this decison should be made by what the client
 Ken> needs/expects, not server design.  If the client only needs a
 Ken> "not to exceed" approximation of the message size, then using
 Ken> the either canonical size or wire format size is fine and we
 Ken> document it as such.  If the client expects the *exact*
 Ken> canonical size, then we have a problem.  My guess is that an
 Ken> approximation is good enough.

Existing clients never need more than an approximation, because the
full spectrum of variations described already exists in deployed
servers.

Now, some aspects of the existing situation are irritatingly
suboptimal (such as the CRLF vs. LF-only confusion) and this is worth
clarifying in the spec. But trying to specify it _exactly_ in a way
that happens to be unreasonably hard to implement on the server will
simply result in it _not_ being implemented on servers - and then the
clients will simply just have to put up with the spec being wrong in
practice.

This is why I suggest specifying the size as being _either_ the
wireformat or canonical format size, because servers should have
little difficulty providing one or the other, or at least a very close
approximation. Any remaining variation is likely to be of the order of
a few tens of bytes at most - which is not likely to cause any
problems for a client _provided_ that the client author is aware of
the inaccuracy.

-- 
Andrew, Supernews
http://www.supernews.com