Keith Moore wrote:
>>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.
>
>
> yes, but that one is completely necessary. if you can't transport
> a rfc 2822 message in SMTP then it isn't likely to go very far.
Practically speaking, true, though there *are* other transport
mechanisms (e.g. UUCP) for which it matters not. And I have
received messages via SMTP with longer lines than 998 octets.
> not that it's a bad idea to bound the length of message-ids, but
> using this as excuse to say that message-ids are bound by the SMTP
> limit on address length is quite a stretch.
That was not my intent. I intended to point out that
1. there exists precedent for transport limits being introduced
into the message format, so in principle that should apply
to a msg-id length limit.
2. It would be more convenient, IMO, to have a uniform limit
for SMTP Path (a.k.a. angle-addr) and for msg-id rather than
two close but different limits. The comparison was by way of
pointing out the historical identity of the constructs (which
now differs w.r.t. CFWS), not as a justification. If there's
a reason why 250 works for NNTP and 256 doesn't, that's another
matter.
While I do think that moving unlimited length msg-ids to the accept
syntax and limiting them in the generate syntax is a good idea, it does
raise the issue of what one does with overly long ids when generating a new
message. Discarding them is probably the cleanest solution.
Ned