On Saturday, February 26, 2005, 08:19:35, Scott Perry wrote: >>Message-Id: <[EMAIL PROTECTED]> > > Actually, RFC822 is still the official standard (per > http://www.rfc-editor.org/rfcxx00.html).
And doing a search at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl for RFC822 shows More Info of "Obsoleted by RFC2822" Searching for RFC2822 shows More Info of "Obsoletes RFC822" http://www.rfc-editor.org/categories/rfc-standard.html says RFC0822 (STD0011) Standard for the format of ARPA Internet text messages (Obsoleted by: RFC2822) > RFC822 has: > msg-id = "<" addr-spec ">" ; Unique message id > addr-spec = local-part "@" domain ; global address > domain = sub-domain *("." sub-domain) > sub-domain = domain-ref / domain-literal > That means that "81.255.84.73" must either be a domain-ref or > domain-literal. Domain-ref and domain-literal are covered by RFC822 > section 6.2.3, which make it pretty clear that the "81.255.84.73" above is > a domain-ref (since it has no brackets), and 81.255.84.73 is clearly not a > valid hostname. domain-ref = atom atom = 1*<any CHAR except specials, SPACE and CTLs> 81, 255, 84 and 73 are all valid instances of atom which means they are valid instances of domain-ref. Therefor 81.255.84.73 meets the ABNF definition of domain. > So the only argument would be whether or not RFC2822 should supersede > RFC822. Even if people felt that it should (which is, like all things RFC, > subject to interpretation!), ... Indeed, I had been curious about RFC821 vs. RFC2821 once and asked: How can a Standard be obsoleted by anything other than another Standard? and got this reply: We are tempted to simply ask, "why not?", but that is probably not helpful. ;-) There is a theoretical answer and a pragmatic one. The theoretical answer is that an implementor today should use RFC 2821 rather than RFC 821. On the other hand, RFC 2821 itself, while it is the desired source for implementors, has not itself reached the maturity to be a full Standard. This state of affairs arises because of the very, very dynamic nature of Internet protocol definitions, a historical fact. RFC 821, like all RFCs, will stay forever in the RFC series, but it is no longer relevant to implementations once it is obsoleted. It is primarily of historical interest. [Some would say that its category should be changed to Historic, therefore, but such changes have not been the general practice in the past 20 years of the Internet standards process.] The pragmatic observation is that the IETF very seldom carries a protocol specification beyond Proposed Standard. If you look into history, you will find that 821 became a Standard as a "lagacy"; it pre-dated the Internet standards process, and never went through the formal progression Proposed Standard -> Draft Standard -> Standard. So 2821 may persist forever, until it is obsoleted by another Proposed Standard, without progressing. Or, it may be obsoleted by a progression to Draft Standard. We hope this is clear. RFC Editor -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." � Ambassador Kosh To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
