Andrew Gierth wrote:
"Mark" == Mark Crispin <mrc(_at_)cac(_dot_)washington(_dot_)edu> writes:
The length limitation of 250 is from existing software rather than
from previous standards (NNTP restricts the total length of a
command-line to 512 including the CRLF). 250 is a better choice
A limit identical to that imposed by other common transports
might be more appropriate. For example, RFC 822 used the
same syntax for msg-id as for angle-brscketed addresses:
msg-id = "<" addr-spec ">" ; Unique message id
and SMTP does have a 256 octet limit on such addresses in
SMTP commands (RFC 821 sect. 4.5.3, RFC 2821 sect. 4.5.3.1).
IMO, a *uniform* limit would be preferable to one arbitrary
limit in one place and a different arbitrary limit in another.
[the same sections of the two SMTP RFCs also impose separate
length limits on the local-part]
Mark> If NNTP has a limitation such as suggested above, then that
Mark> would add a transport imposed requirement to a document that
Mark> otherwise uses RFC 2822 and MIME as normative. That is
Mark> something that can be respected.
There also appears to be precedent for such transport limits
finding their way into the message format specification. RFC 822
had no line length limit; the 998 octet limit in 2822 sections
2.1.1, 2.3, and 3.5 appears to be derived from the SMTP transport
limitation.
Mark> That is different from duplicating all of RFC 2822 and MIME
Mark> just to insert transport imposed requirements. Doing so, which
Mark> the Usefor document has done, is ludicrous.
I believe that the motivation was introduction of raw utf-8, rather
than transport requirements. Yes, it's ludicrous -- better to
address any desired extensions in a general manner, and likewise
for ambiguities in the MIME documents. The appropriate mechanism
is the usual evolution of the relevant standards; that way any
potential incompatibilities will quickly become apparent and can
be communicated and resolved. That is certainly preferable to
a thinly-cloaked attempt to force incompatibilities on
interoperating protocols.
it is not, in fact, merely an NNTP issue; message-ids are a key part
of _every_ news transport method (since they are used to detect
duplicates). Every news server has to keep a history database (or the
moral equivalent) indexed by message-id, whether it uses NNTP or not.
Message-ids are passed around a lot internally, stored in queue files,
listed in ihave/sendme control messages for UUCP feeding, appear as
parameters in control messages, and generally pervade the entire
structure of news; whitespace or excessive length breaks things in
really quite a lot of places.
Andrew, you mentioned that the control characters and '>' which
can appear (backslash-quoted inside a no-fold-quote) in a legal
2822 msg-id are problematic. Are those NNTP issues or implementation
issues? [for the moment, let's ignore the plethora of issues that
theoretically could arise similarly in a no-fold-literal (which
appears to be future-prediction on the part of 2822); let's
assume that the RHS is either a domain name consisting of only
letters, digits, and hyphen or is a valid IPv4 or IPv6 IP literal]