From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Sun Feb 10 2002 - 16:25:39 CST
*** draft-ietf-usefor-article-06.unpaged Mon Dec 10 11:38:31 2001
--- draft-ietf-usefor-article-06.01.unpaged Fri Feb 8 22:53:11 2002
***************
*** 3,5 ****
Usenet Format Working Group University of Manchester
! November 2001
--- 3,5 ----
Usenet Format Working Group University of Manchester
! February 2002
***************
*** 6,8 ****
News Article Format
! <draft-ietf-usefor-article-06.txt>
--- 6,8 ----
News Article Format
! <draft-ietf-usefor-article-06.01.txt>
***************
*** 32,42 ****
! This Draft defines the format of Netnews articles and specifies
! the requirements to be met by software which originates,
! distributes, stores and displays them. It is intended as a
! standards track document, superseding RFC 1036, which itself dates
! from 1987.
Since the 1980s, Usenet has grown explosively, and many Internet and
! non-Internet sites now participate. In addition, this technology is
! now in widespread use for other purposes.
--- 32,43 ----
! This Draft It is intended as a standards track document,
! obsoleting RFC 1036, which itself dates from 1987.
+ This Standard defines the format of Netnews articles and specifies
+ the requirements to be met by software which originates, distributes,
+ stores and displays them.
+
Since the 1980s, Usenet has grown explosively, and many Internet and
! non-Internet sites now participate. In addition, the Netnews
! technology is now in widespread use for other purposes.
***************
*** 58,63 ****
! [Please note that this Draft describes "Work in Progress". Much remains
! to be done, though the material included so far is unlikely to change in
! any major way.]
--- 59,67 ----
+ [In this draft, references to [NNTP] are to be replaced by [RFC 977], or
+ else by references to the RFC arising from the series of drafts draft-
+ ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at
+ the time this document is published.]
! [Please note that this Draft describes "Work in Progress", though the
! material included here is unlikely to change in any major way.]
***************
*** 75,77 ****
2.3. Relation To Mail and MIME ................................. 0
! 2.4. Syntax Notation ........................................... 0
2.5. Language .................................................. 0
--- 79,84 ----
2.3. Relation To Mail and MIME ................................. 0
! 2.4. Syntax .................................................... 0
! 2.4.1. Syntax Notation ....................................... 0
! 2.4.2. Syntax adapted from Email and MIME .................... 0
! 2.4.3. Syntax copied from oither standards ................... 0
2.5. Language .................................................. 0
***************
*** 111,115 ****
5.6.1. Format ................................................ 0
! 5.6.2. Adding a path-identity to the Path header ............. 0
5.6.3. The tail-entry ........................................ 0
! 5.6.4. Delimiter Summary ..................................... 0
5.6.5. Suggested Verification Methods ........................ 0
--- 118,122 ----
5.6.1. Format ................................................ 0
! 5.6.2. Adding a path-identity to the Path-header ............. 0
5.6.3. The tail-entry ........................................ 0
! 5.6.4. Path-Delimiter Summary ................................ 0
5.6.5. Suggested Verification Methods ........................ 0
***************
*** 139,141 ****
6.19. Injector-Info ............................................ 0
! 6.19.1. Usage of Injector-Info-header-parameters ............. 0
6.19.1.1. The posting-host-parameter ....................... 0
--- 146,148 ----
6.19. Injector-Info ............................................ 0
! 6.19.1. Usage of Injector-Info-parameters .................... 0
6.19.1.1. The posting-host-parameter ....................... 0
***************
*** 202,204 ****
13. Contact Addresses ............................................ 0
- 14. Intellectual Property Rights ................................. 0
Appendix A.1 - A-News Article Format .............................. 0
--- 209,210 ----
***************
*** 208,211 ****
Appendix B - Collected Syntax ..................................... 0
-
1. Introduction
--- 214,223 ----
Appendix B - Collected Syntax ..................................... 0
+ Appendix B.1 Characters, Atoms and Folding ........................ 0
+ Appendix B.2 Basic Forms .......................................... 0
+ Appendix B.3 Headers .............................................. 0
+ Appendix B.3.1 Template definitions ............................... 0
+ Appendix B.3.2 Template instantiations ............................ 0
+ Appendix B.3.3 Other header rules ................................. 0
+ Appendix C - Notices
1. Introduction
***************
*** 366,369 ****
An article's "reply address" is the address to which mailed replies
! should be sent. This is the address specified in the article's From
! header (5.2), unless it also has a Reply-To header (6.1).
--- 378,381 ----
An article's "reply address" is the address to which mailed replies
! should be sent. This is the address specified in the article's From-
! header (5.2), unless it also has a Reply-To-header (6.1).
***************
*** 460,464 ****
NOTE: A requirement imposed on a relaying or serving agent
! should be understood as applying only to articles actually
! accepted for processing by that agent (since any agent may
! always reject any article entirely, for reasons of site policy).
--- 472,477 ----
NOTE: A requirement imposed on a relaying or serving agent
! regarding some particular article should be understood as
! applying only if that article is actually accepted for
! processing (since any agent may always reject any article
! entirely, for reasons of site policy).
***************
*** 493,501 ****
! 2.4. Syntax Notation
This standard uses the Augmented Backus Naur Form described in [RFC
! 2234]. A discussion of this is outside the bounds of this standard,
! but it is expected that implementors will be able quickly to
! understand it with reference to that defining document.
Much of the syntax of News Articles is based on the corresponding
--- 506,535 ----
! 2.4. Syntax
+
+
+
+
+ 2.4.1. Syntax Notation
+
This standard uses the Augmented Backus Naur Form described in [RFC
! 2234]. Additionally, some syntax rules are given in the form of
! schemata from each of which several rules in the [RFC 2234] format
! can be derived. For example, the schema
+ {USENET}-header = {USENET}-name ":" 1*SP {USENET}-content
+ *( [CFWS] ";" ( {USENET}-parameter /
+ other-parameter ) )
+
+ (see section 4.1) implies the existence of a large number of rules,
+ one for each header defined by this standard. Substituting the
+ template "{USENET}" by, for example, "Archive" thus gives rise to the
+ actual rule
+
+ Archive-header = Archive-name ":" 1*SP Archive-content
+ *( [CFWS] ";" ( Archive-parameter /
+ other-parameter ) )
+
+ 2.4.2. Syntax adapted from Email and MIME
+
Much of the syntax of News Articles is based on the corresponding
***************
*** 506,508 ****
US-ASCII characters, that it does not recognise the MIME headers [RFC
! 2045], and that it includes much syntax described as "obsolete".
--- 540,543 ----
US-ASCII characters, that it does not recognise the MIME headers [RFC
! 2045], and that it includes much syntax described as "obsolete"
! (which is excluded from this standard, as detailed below).
***************
*** 534,535 ****
--- 569,571 ----
UTF8-xtra-char
+
ctext = NO-WS-CTL / ; all of <text> except
***************
*** 553,555 ****
%d35-91 /
! %d93-127
strict-quoted-pair
--- 589,591 ----
%d35-91 /
! %d93-126
strict-quoted-pair
***************
*** 556,559 ****
= "\" strict-text
-
-
strict-qcontent = strict-qtext / strict-quoted-pair
--- 592,593 ----
***************
*** 560,564 ****
strict-quoted-string
! = [CFWS]
! DQUOTE *([FWS] strict-qcontent) [FWS] DQUOTE
! [CFWS]
--- 594,598 ----
strict-quoted-string
! = [CFWS] DQUOTE
! *( [FWS] strict-qcontent ) [FWS]
! [CFWS] DQUOTE
***************
*** 583,584 ****
--- 617,620 ----
+ 2.4.3. Syntax copied from oither standards
+
The following syntactic forms, taken from [RFC 2234] or from [RFC
***************
*** 603,605 ****
":" / ";" /
! "@" / "
"," / "." /
--- 639,641 ----
":" / ";" /
! "@" / "\" /
"," / "." /
***************
*** 611,617 ****
CFWS = *([FWS] comment) (([FWS] comment) / FWS )
! DQUOTE = %d34 ; quote mark
quoted-pair = "\" text
-
-
-
atext = ALPHA / DIGIT /
--- 647,650 ----
CFWS = *([FWS] comment) (([FWS] comment) / FWS )
! DQUOTE = %d34 ; quote mark
quoted-pair = "\" text
atext = ALPHA / DIGIT /
***************
*** 624,626 ****
"^" / "_" /
! "`" / "}" /
"|" / "}" /
--- 657,659 ----
"^" / "_" /
! "`" / "{" /
"|" / "}" /
***************
*** 631,635 ****
qcontent = qtext / quoted-pair
! quoted-string = [CFWS]
! DQUOTE *([FWS] qcontent) [FWS] DQUOTE
! [CFWS]
word = atom / quoted-string
--- 664,668 ----
qcontent = qtext / quoted-pair
! quoted-string = [CFWS] DQUOTE
! *( [FWS] qcontent ) [FWS]
! [CFWS] DQUOTE
word = atom / quoted-string
***************
*** 636,638 ****
phrase = 1*word
- unstructured = *( [FWS] utext ) [FWS]
--- 669,670 ----
***************
*** 670,675 ****
-
-
-
-
3. Changes to the existing protocols
--- 702,703 ----
***************
*** 688,692 ****
headers are supported.
! o Whitespace is permitted in Newsgroups headers, permitting folding
of such headers. Indeed, all news headers can now be folded.
! o An enhanced syntax for the Path header enables the injection
point of and the route taken by an article to be determined with
--- 716,720 ----
headers are supported.
! o Whitespace is permitted in Newsgroups-headers, permitting folding
of such headers. Indeed, all news headers can now be folded.
! o An enhanced syntax for the Path-header enables the injection
point of and the route taken by an article to be determined with
***************
*** 693,695 ****
certainty.
! o Netnews is firmly established as an 8bit medium.
o Large parts of MIME are recognised as an integral part of
--- 721,725 ----
certainty.
! o Netnews is firmly established as an 8bit medium and all headers
! are deemed to be in the UTF-8 character set (thus permitting, in
! particular, the use of Non-ASCII newsgroup-names).
o Large parts of MIME are recognised as an integral part of
***************
*** 698,703 ****
permit newsgroup-names with non-ASCII characters.
! o There is a new Control command 'mvgroup' to facilitate moving a
group to a different place (name) in a hierarchy.
! o There are several new headers defined, such as Injector-Info and
! Author-Ids, leading to increased functionality.
o There are numerous other small changes, clarifications and
--- 728,736 ----
permit newsgroup-names with non-ASCII characters.
! o There is a new Control message 'mvgroup' to facilitate moving a
group to a different place (name) in a hierarchy.
! o There are several new headers defined, such as Archive,
! Complaints-To, Injector-Info, Mail-Copies-To, Posted-And-Mailed
! and User-Agent, leading to increased functionality.
! o Certain headers and Control messages (AppendixA.3 and Appendix
! A.4) have been made obsolete.
o There are numerous other small changes, clarifications and
***************
*** 704,709 ****
enhancements.
- [Doubtless many other changes should be listed, but there is little
- point in doing so until our text is nearing completion. The above gives
- the flavour of what should be said. There should also be references to
- Appendix A.3 and Appendix A.4 ]
--- 737,738 ----
***************
*** 730,742 ****
o [RFC 2822] style comments in headers do not affect serving and
! relaying agents (note that the Newsgroups and Path headers do not
! contain them). They are unlikely to hinder their proper display
! in existing user agents except in the case of the References
! header in agents which thread articles. Therefore, it is provided
! that they SHOULD NOT be generated except where permitted by the
! previous standards.
o Because of its importance to all serving agents, the extension
! permitting whitespace and folding in Newsgroup headers SHOULD NOT
! be used until it has been widely deployed amongst relaying
agents. User agents are unaffected.
! o The new style of Path header is already consistent with the
previous standards. However, the intention is that relaying
--- 759,771 ----
o [RFC 2822] style comments in headers do not affect serving and
! relaying agents (note that the Newsgroups-, Distribution- and
! Path-headers do not contain them). They are unlikely to hinder
! their proper display in existing user agents except in the case
! of the References-header in agents which thread articles.
! Therefore, it is provided that they SHOULD NOT be generated
! except where permitted by the previous standards.
o Because of its importance to all serving agents, the extension
! permitting whitespace and folding in Newsgroups-headers SHOULD
! NOT be used until it has been widely deployed amongst relaying
agents. User agents are unaffected.
! o The new style of Path-header is already consistent with the
previous standards. However, the intention is that relaying
***************
*** 743,746 ****
agents should eventually reject articles in the old style, and so
! this should be offered as a configurable option for relaying
! agents. User agents are unaffected.
o The vast majority of serving, relaying and transport agents are
--- 772,775 ----
agents should eventually reject articles in the old style, and so
! this possibility should be offered as a configurable option in
! relaying agents. User agents are unaffected.
o The vast majority of serving, relaying and transport agents are
***************
*** 764,782 ****
Insofar as newsgroup names containing non-ASCII characters can
! now be expected to arise, support from serving and relaying
! agents will be necessary. It is believed that the customary
! storage structure used by serving agents can already cope
! (perhaps not ideally) with such names. Note that it is not
! necessary for serving and relaying agents to understand all the
! characters available in UTF-8, though it is desirable for them to
! be displayable for diagnostic purposes via some escape mechanism
! using, for example, the visible subset of US-ASCII. For users
! expecting to use the more exotic possibilities available under
! UTF-8, the remarks already made in connection with MIME will
! apply.
o The new Control: mvgroup command will need to be implemented in
! serving agents. It SHOULD be used in conjunction with pairs of
! matching rmgroup and newgroup commands (injected shortly after
! the mvgroup) until such time as mvgroup is widely implemented.
! User agents are unaffected.
! o The headers newly introduced by this standard can safely be
ignored by existing software, albeit with loss of the new
--- 793,814 ----
Insofar as newsgroup names containing non-ASCII characters can
! now be expected to arise, some support from serving and relaying
! agents will be desirable, although it has been established that
! most current serving agents can already cope with such names
! without modification (although perhaps not in an ideal manner).
! Note that it is not necessary for serving and relaying agents to
! understand all the characters available in UTF-8, though it is
! desirable for them to be displayable for diagnostic purposes via
! some escape mechanism using, for example, the visible subset of
! US-ASCII. For users expecting to use the more exotic
! possibilities available under UTF-8, the remarks already made in
! connection with MIME will apply.
o The new Control: mvgroup command will need to be implemented in
! serving agents. For the benefit of older serving agents it is
! therefore RECOMMENDED that it be followed shortly by a
! corresponding newgroup command and it MUST always be followed by
! a rmgroup command for the old group after a reasonable overlap
! period. An implementation of the mvgroup command as an alias for
! the newgroup command would thus be minimally conforming. User
! agents are unaffected.
! o All the headers newly introduced by this standard can safely be
ignored by existing software, albeit with loss of the new
***************
*** 786,791 ****
-
-
-
-
4.1. Syntax of News Articles
--- 818,819 ----
***************
*** 794,797 ****
! article = 1*header separator body
! header = header-name ":" 1*SP header-content CRLF
header-name = 1*name-character *( "-" 1*name-character )
--- 822,831 ----
! article = 1*( header CRLF ) separator body
! header = {USENET}-header / other-header
! {USENET}-header = {USENET}-name ":" 1*SP {USENET}-content
! *( [CFWS] ";" ( {USENET}-parameter /
! other-parameter ) )
! {USENET}-name = <a header-name defined in this standard
! (or an extension of it) for a specific
! {USENET}-header>
header-name = 1*name-character *( "-" 1*name-character )
***************
*** 798,825 ****
name-character = ALPHA / DIGIT
! header-content = USENET-header-content
! *( [CFWS] ";" header-parameter ) /
! other-header-content
! USENET-header-content
! = <the header-content defined in this standard
! (or an extension of it) for a specific
! USENET header>
! other-header-content
! = <a header-content defined (explicitly or
! implicitly) by some other standard>
! header-parameter = USENET-header-parameter /
! other-header-parameter
! USENET-header-parameter
! = <an other-header-parameter defined in
! this standard for use in conjunction with
! a specific USENET-header-content>
! other-header-parameter
! = attribute "=" value
! attribute = USENET-token / iana-token / x-token
! value = token / quoted-string
! USENET-token = <A token defined in this standard for
! use in conjunction with a specific
! USENET-header-parameter>
! iana-token = <A token defined in an experimental
! or standards-track RFC and registered with
! IANA>
x-token = [CFWS] "x-" token-core [CFWS]
--- 832,847 ----
name-character = ALPHA / DIGIT
! {USENET}-content = <the content of a header defined in this
! standard (or an extension of it) for a
! specific {USENET}-header>
! {USENET}-parameter= <an other-parameter defined in this standard
! (or an extension of it) for a specific
! {USENET}-header>
! other-parameter = attribute "=" value
! attribute = {USENET}-token / iana-token / x-token
! {USENET}-token = <A token defined in this standard for
! use in conjunction with a specific
! {USENET}-parameter>
! iana-token = <a token defined in an experimental
! or standards-track RFC and registered
! with IANA>
x-token = [CFWS] "x-" token-core [CFWS]
***************
*** 827,829 ****
token-core = 1*<any (US-ASCII) CHAR except SP, CTLs,
! or tspecials>
tspecials = "(" / ")" / "<" / ">" / "@" /
--- 849,851 ----
token-core = 1*<any (US-ASCII) CHAR except SP, CTLs,
! or tspecials>
tspecials = "(" / ")" / "<" / ">" / "@" /
***************
*** 831,832 ****
--- 853,859 ----
"/" / "[" / "]" / "?" / "="
+ value = token / quoted-string
+ other-header = header-name ":" 1*SP other-content
+ other-content
+ = <the content of a header defined by some
+ other standard>
separator = CRLF
***************
*** 861,863 ****
Despite the restrictions on header-name syntax imposed by the
! grammar, relayers and reading agents SHOULD tolerate header names
containing any US-ASCII printable character other than colon (":",
--- 888,890 ----
Despite the restrictions on header-name syntax imposed by the
! grammar, relayers and reading agents SHOULD tolerate header-names
containing any US-ASCII printable character other than colon (":",
***************
*** 865,872 ****
! Header-names SHOULD be either those for which a USENET-header-content
! is established by this standard, or by [RFC 2822], or by any
! extension to either of these standards including, in particular, the
! MIME standards [RFC 2045] et seq., or else experimental headers
! beginning with "X-" (as defined in 4.2.2.1). Software SHOULD NOT
! attempt to interpret headers not described in this standard or in its
extensions, but relaying agents MUST pass them on unaltered and
--- 892,899 ----
! Header-names SHOULD be either those for which a {USENET}-content is
! established by this standard, or by [RFC 2822], or by any extension
! to either of these standards including, in particular, the MIME
! standards [RFC 2045] et seq., or else experimental headers beginning
! with "X-" (as defined in 4.2.2.1). Software SHOULD NOT attempt to
! interpret headers not described in this standard or in its
extensions, but relaying agents MUST pass them on unaltered and
***************
*** 874,885 ****
! The possibility of allowing header-parameters to appear in all
! headers is provided mainly for the purpose of allowing future
! extensions to existing headers, since only a very few USENET-header-
parameters are actually defined in this standard. Observe that such
! header-parameters do not, in general, occur in headers defined in
! other standards, except for the MIME standards [RFC 2045] et seq. and
! their extensions. Nevertheless, compliant software MUST accept all
! such header-parameters in headers defined by this standard and its
! extensions (ignoring them if their meaning is unknown) and SHOULD
! accept (and ignore) them in all headers.
[but what about
--- 901,933 ----
! [Alternative paragraph]
!
! Whilst relaying agents MUST accept, and pass on unaltered, any non-
! variant header whose header-name is syntactically correct, and
! reading agents MUST enable them to be displayed, at least optionally,
! posting and injecting agents SHOULD NOT generate headers other than
! o those for which a {USENET}-content is established by this
! standard or any extension to it,
! o those recognised by other IESG-established standards, notably the
! email standard [RFC 2822] and its extensions (including any IANA
! registry of recognised headers that may be established in the
! future),
! o experimental headers beginning with "X-" (as defined in 4.2.2.1),
! o on a provisional basis only, headers related to new protocols
! under delevopment which are the subject of (or intended to be the
! subect of) some IESG-approved RFC (whether Informational,
! Experimental or Standards-Track).
! However, software SHOULD NOT attempt to interpret headers not
! specifically intended to be meaningful in the Netnews environment.
! [End of alternative paragraph]
!
! The possibility of allowing {USENET}- or other-parameters to appear
! in all headers is provided mainly for the purpose of allowing future
! extensions to existing headers, since only a very few {USENET}-
parameters are actually defined in this standard. Observe that such
! parameters do not, in general, occur in headers defined in other
! standards, except for the MIME standards [RFC 2045] et seq. and their
! extensions. Nevertheless, compliant software MUST accept all such
! parameters in headers defined by this standard and its extensions
! (ignoring them if their meaning is unknown) and SHOULD accept (and
! ignore) them in all headers.
[but what about
***************
*** 889,910 ****
! NOTE: The presence of a ";" in a header-content does not
! indicate the presence of a header-parameter in the few
! situations where it can be parsed as part of some USENET-
! header-content or other-header-content.
! On the other hand, posting agents SHOULD NOT generate header-
! parameters (even those using x-tokens) except in those headers for
! which a USENET-header-parameter has been defined, or where that usage
! is permitted by some other standard (notably one of the MIME
! standards). This restriction is likely to removed in a future version
! of this standard.
! NOTE: The given syntax is ambiguous insofar as a USENET-header-
! content that is defined to be <unstructured> could contain,
! within that <unstructured>, text of the form <*(";" header-
parameter)>. The intention is therefore that any such apparent
! header-parameters are to be regarded as part of the
! <unstructured>. This standard therefore does not (and extensions
! to it SHOULD NOT) define any USENET-header-parameter to be
! associated with such an unstructured USENET-header-content.
--- 937,958 ----
! NOTE: The presence of a ";" in a {USENET}-content does not
! indicate the presence of a {USENET}- or other-parameter in the
! few situations where it can be parsed as part of some {USENET}-
! content.
! On the other hand, posting agents SHOULD NOT generate parameters
! (even those using x-tokens) except in those headers for which a
! {USENET}-parameter has been defined, or where that usage is permitted
! by some other standard (notably one of the MIME standards). This
! restriction is likely to be removed in a future version of this
! standard.
! NOTE: The given syntax is ambiguous insofar as an unstructured
! {USENET}-content, i.e. one composed entirely from characters in
! <utext>, could contain text of the form <*(";" other-
parameter)>. The intention is therefore that any such apparent
! parameters are to be regarded as part of the unstructured
! content. This standard therefore does not (and extensions to it
! SHOULD NOT) define any {USENET}-parameter to be associated with
! such an unstructured {USENET}-content.
***************
*** 922,927 ****
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
! used in this standard are the preferred forms for the headers
! described herein. Relaying and reading agents MUST, however, tolerate
! articles not obeying this convention.
4.2.2. Header Properties
--- 970,978 ----
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
! given in the various {USENET}-name rules in this standard are the
! preferred forms for the headers described herein. Relaying and
! reading agents MUST, however, tolerate articles not obeying this
! convention.
+
+
4.2.2. Header Properties
***************
*** 946,947 ****
--- 997,1012 ----
+ [Alternative paragraph]
+
+ Experimental headers are those whose header-names begin with "X-".
+ They are to be used for experimental Netnews features, or for
+ enabling additional material to be propagated with an article. They
+ are not (and will not be) defined by this, or any, standard.
+
+ NOTE: Experimental headers are suitable for situations where
+ they need only to be human readable. They are not intended to be
+ recognised by widely deployed Netnews software and, should such
+ a requirement be envisaged, it is preferable to use a normal
+ header on the provisional basis set out in section 4.2.1.
+ [End of alternative paragraph]
+
4.2.2.2. Inheritable Headers
***************
*** 954,956 ****
o Newsgroups (5.5) - copied from the precursor, subject to any
! Followup-To header.
o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
--- 1019,1021 ----
o Newsgroups (5.5) - copied from the precursor, subject to any
! Followup-To-header.
o Subject (5.4) - modified by prefixing with "Re: ", but otherwise
***************
*** 961,963 ****
! NOTE: The Keywords header is not inheritable, though some older
newsreaders treated it as such.
--- 1026,1028 ----
! NOTE: The Keywords-header is not inheritable, though some older
newsreaders treated it as such.
***************
*** 964,966 ****
-
4.2.2.3. Variant Headers
--- 1029,1030 ----
***************
*** 985,992 ****
Each header is logically a single line of characters comprising the
! header-name, the colon with its following SP, and the header-content.
! For convenience, however, the header-content can be split into a
! multiple line representation; this is called "folding". The general
! rule is that wherever this standard allows for FWS or CFWS (but not
! simply SP or HTAB) a CRLF may be inserted before any WSP. For
! example, the header:
Approved: modname@modsite.example (Moderator of comp.foo.bar)
--- 1049,1056 ----
Each header is logically a single line of characters comprising the
! header-name, the colon with its following SP, and the {USENET}- or
! other-content. For convenience, however, the header-content can be
! split into a multiple line representation; this is called "folding".
! The general rule is that wherever this standard allows for FWS or
! CFWS (but not simply SP or HTAB) a CRLF may be inserted before any
! WSP. For example, the header:
Approved: modname@modsite.example (Moderator of comp.foo.bar)
***************
*** 1008,1010 ****
! The colon following the header name on the first line MUST be
followed by a WSP, even if the header is empty. If the header is not
--- 1072,1074 ----
! The colon following the header-name on the first line MUST be
followed by a WSP, even if the header is empty. If the header is not
***************
*** 1032,1037 ****
Strings of characters which are treated as comments may be included
! in header-contents wherever the syntactic element CFWS occurs. They
! consist of characters enclosed in parentheses. Such strings are
! considered comments so long as they do not appear within a quoted-
! string. Comments may be nested.
--- 1096,1101 ----
Strings of characters which are treated as comments may be included
! in {USENET}- or other-contents wherever the syntactic element CFWS
! occurs. They consist of characters enclosed in parentheses. Such
! strings are considered comments so long as they do not appear within
! a quoted-string. Comments may be nested.
***************
*** 1060,1062 ****
From and similar headers, and to indicate the name of the timezone in
! Date headers. However, compliant software MUST accept them in all
places where they are syntactically allowed.
--- 1124,1126 ----
From and similar headers, and to indicate the name of the timezone in
! Date-headers. However, compliant software MUST accept them in all
places where they are syntactically allowed.
***************
*** 1073,1077 ****
! Headers that merely state defaults explicitly (e.g., a Followup-To
! header with the same content as the Newsgroups header, or a MIME
! Content-Type header with contents "text/plain; charset=us-ascii") or
state information that reading agents can typically determine easily
--- 1137,1141 ----
! Headers that merely state defaults explicitly (e.g., a Followup-To-
! header with the same content as the Newsgroups-header, or a MIME
! Content-Type-header with contents "text/plain; charset=us-ascii") or
state information that reading agents can typically determine easily
***************
*** 1080,1082 ****
-
4.3. Body
--- 1144,1145 ----
***************
*** 1083,1084 ****
--- 1146,1151 ----
+
+
+
+
4.3.1. Body Format Issues
***************
*** 1129,1131 ****
A body is by default an uninterpreted sequence of octets for most of
! the purposes of this standard. However, a MIME Content-Type header
may impose some structure or intended interpretation upon it, and may
--- 1196,1198 ----
A body is by default an uninterpreted sequence of octets for most of
! the purposes of this standard. However, a MIME Content-Type-header
may impose some structure or intended interpretation upon it, and may
***************
*** 1199,1200 ****
--- 1266,1268 ----
+
4.4. Characters and Character Sets
***************
*** 1213,1215 ****
encoding scheme (UTF-8 for headers, and determined by the Content-
! Type and Content-Transfer-Encoding headers for bodies).
--- 1281,1283 ----
encoding scheme (UTF-8 for headers, and determined by the Content-
! Type- and Content-Transfer-Encoding-headers for bodies).
***************
*** 1243,1255 ****
characters from Unicode are represented by sequences of octets
! satisfying the syntax of a UTF8-xtra-char (2.4), which excludes
! certain octet sequences not explicitly permitted by [RFC 2279].
! Unicode includes all characters from the ISO-8859 series of
! characters sets [ISO 8859] (which includes all Cyrillic, Greek
! and Arabic characters) together with the more elaborate
! characters used in Asian countries. See the following section
! for the appropriate treatment of Unicode characters by reading
! agents.
-
-
Notwithstanding the great flexibility permitted by UTF-8, there is
--- 1311,1321 ----
characters from Unicode are represented by sequences of octets
! satisfying the syntax of a UTF8-xtra-char (2.4.2), which
! excludes certain octet sequences not explicitly permitted by
! [RFC 2279]. Unicode includes all characters from the ISO-8859
! series of characters sets [ISO 8859] (which includes all
! Cyrillic, Greek and Arabic characters) together with the more
! elaborate characters used in Asian countries. See the following
! section for the appropriate treatment of Unicode characters by
! reading agents.
Notwithstanding the great flexibility permitted by UTF-8, there is
***************
*** 1261,1265 ****
domains and path-identities - MUST be in US-ASCII. Comments, phrases
! (as in addresses) and unstructureds (as in Subject headers) MAY use
! the full range of UTF-8 characters, but SHOULD nevertheless be
! invariant under Unicode normalization NFC [UNICODE 3.1].
--- 1327,1332 ----
domains and path-identities - MUST be in US-ASCII. Comments, phrases
! (as in addresses) and unstructured headers (such as the Subject-,
! Organization- and Summary-headers) MAY use the full range of UTF-8
! characters, but SHOULD nevertheless be invariant under Unicode
! normalization NFC [UNICODE 3.1].
***************
*** 1293,1296 ****
Within article bodies, characters are represented as octets according
! to the encoding scheme implied by any Content-Transfer-Encoding and
! Content-Type headers [RFC 2045]. In the absence of such headers,
reading agents cannot be relied upon to display correctly more than
--- 1360,1363 ----
Within article bodies, characters are represented as octets according
! to the encoding scheme implied by any Content-Transfer-Encoding- and
! Content-Type-headers [RFC 2045]. In the absence of such headers,
reading agents cannot be relied upon to display correctly more than
***************
*** 1314,1315 ****
--- 1381,1383 ----
+
Followup agents MUST be careful to apply appropriate encodings to the
***************
*** 1371,1372 ****
--- 1439,1442 ----
+
+
4.6. Example
***************
*** 1407,1409 ****
Note also that there are situations, discussed in the relevant parts
! of section 6, where References, Sender, or Approved headers are
mandatory. In control messages, specific values are required for
--- 1477,1479 ----
Note also that there are situations, discussed in the relevant parts
! of section 6, where References-, Sender-, or Approved-headers are
mandatory. In control messages, specific values are required for
***************
*** 1412,1417 ****
For the overall syntax of headers, see section 4.1. In the
! discussions of the individual headers, the content of each is
! specified using the syntax notation. The convention used is that the
! content of, for example, the Subject header is defined as <Subject-
! content>.
--- 1482,1487 ----
For the overall syntax of headers, see section 4.1. In the
! discussions of the individual headers, the name and content of each
! is specified using the syntax notation. The convention used is that
! the name of, for example, the Subject-header is defined as <Subject-
! name> and its content as <Subject-content>.
***************
*** 1422,1424 ****
! The Date header contains the date and time that the article was
prepared by the poster ready for transmission and SHOULD express the
--- 1492,1494 ----
! The Date-header contains the date and time that the article was
prepared by the poster ready for transmission and SHOULD express the
***************
*** 1428,1429 ****
--- 1498,1500 ----
+ Date-name = "Date"
Date-content = date-time
***************
*** 1446,1448 ****
In order to prevent the reinjection of expired articles into the news
! stream, relaying and serving agents MUST refuse articles whose Date
header predates the earliest articles of which they normally keep
--- 1517,1519 ----
In order to prevent the reinjection of expired articles into the news
! stream, relaying and serving agents MUST refuse articles whose Date-
header predates the earliest articles of which they normally keep
***************
*** 1450,1452 ****
MAY use a margin less than that 24 hours). Relaying agents MUST NOT
! modify the Date header in transit.
--- 1521,1523 ----
MAY use a margin less than that 24 hours). Relaying agents MUST NOT
! modify the Date-header in transit.
***************
*** 1460,1462 ****
! The From header contains the electronic address(es), and possibly the
full name, of the article's poster(s). The content syntax makes use
--- 1531,1533 ----
! The From-header contains the electronic address(es), and possibly the
full name, of the article's poster(s). The content syntax makes use
***************
*** 1465,1466 ****
--- 1536,1538 ----
+ From-name = "From"
From-content = mailbox-list
***************
*** 1478,1480 ****
to the poster(s) of the article, or person or agent on whose behalf
! the post is being sent (see the Sender header, 6.2). When, for
whatever reason, the poster does not wish to include such an
--- 1550,1552 ----
to the poster(s) of the article, or person or agent on whose behalf
! the post is being sent (see the Sender-header, 6.2). When, for
whatever reason, the poster does not wish to include such an
***************
*** 1483,1484 ****
--- 1555,1557 ----
+
NOTE: Since such addresses ending in ".invalid" are
***************
*** 1491,1495 ****
! Be warned also that some injecting agents that have
! authentication information may choose to replace the From-
! content based upon the authenticated identity.
--- 1564,1569 ----
! Be warned, however, that some injecting agents which are unable
! to detect that the address belongs to the poster may choose to
! insert a Sender-header (6.2) or some entry in an Injector-Info-
! header (6.19) which discloses some valid address for the poster.
***************
*** 1514,1516 ****
! The Message-ID header contains the article's message identifier, a
unique identifier distinguishing the article from every other
--- 1588,1590 ----
! The Message-ID-header contains the article's message identifier, a
unique identifier distinguishing the article from every other
***************
*** 1520,1521 ****
--- 1594,1596 ----
+ Message-ID-name = "Message-ID"
Message-ID-content = msg-id
***************
*** 1538,1539 ****
--- 1613,1615 ----
+
Following the provisions of [RFC 2822], an agent generating an
***************
*** 1544,1546 ****
NOT be altered in any way during transport, or when copied (as into a
! References header), and thus a simple (case-sensitive) comparison of
octets will always suffice to recognise that same message identifier
--- 1620,1622 ----
NOT be altered in any way during transport, or when copied (as into a
! References-header), and thus a simple (case-sensitive) comparison of
octets will always suffice to recognise that same message identifier
***************
*** 1555,1560 ****
! The Subject header contains a short string identifying the topic of
the message. This is an inheritable header (4.2.2.2) to be copied
! into the Subject header of any followup, in which case the new
! header-content SHOULD then default to the string "Re: " (a "back
reference") followed by the contents of the pure-subject of the
--- 1631,1636 ----
! The Subject-header contains a short string identifying the topic of
the message. This is an inheritable header (4.2.2.2) to be copied
! into the Subject-header of any followup, in which case the new
! Subject-content SHOULD then default to the string "Re: " (a "back
reference") followed by the contents of the pure-subject of the
***************
*** 1562,1563 ****
--- 1638,1640 ----
+ Subject-name = "Subject"
Subject-content = [ back-reference ] pure-subject
***************
*** 1594,1596 ****
Subject-content of a control message (i.e. an article that also
! contains a Control header) MAY start with the string "cmsg ", and
non-control messages MUST NOT start with the string "cmsg ". See also
--- 1671,1673 ----
Subject-content of a control message (i.e. an article that also
! contains a Control-header) MAY start with the string "cmsg ", and
non-control messages MUST NOT start with the string "cmsg ". See also
***************
*** 1598,1603 ****
-
-
-
-
5.4.1. Examples
--- 1675,1676 ----
***************
*** 1617,1622 ****
! The Newsgroups header's content specifies the newsgroup(s) in which
the article is intended to appear. It is an inheritable header
! (4.2.2.2) which then becomes the default Newsgroups header of any
! followup, unless a Followup-To header is present to prescribe
otherwise.
--- 1690,1695 ----
! The Newsgroups-header's content specifies the newsgroup(s) in which
the article is intended to appear. It is an inheritable header
! (4.2.2.2) which then becomes the default Newsgroups-header of any
! followup, unless a Followup-To-header is present to prescribe
otherwise.
***************
*** 1635,1636 ****
--- 1708,1710 ----
+ Newsgroups-name = "Newsgroups"
Newsgroups-content = newsgroup-name
***************
*** 1643,1645 ****
combiner-base = combiner-ASCII / combiner-extended
! combiner-ASCII = "0"-"9" / %x41-5A / %x61-7A / "+" / "-" / "_"
combiner-extended = <any character with a Unicode code value of
--- 1717,1719 ----
combiner-base = combiner-ASCII / combiner-extended
! combiner-ASCII = DIGIT / ALPHA / "+" / "-" / "_"
combiner-extended = <any character with a Unicode code value of
***************
*** 1698,1700 ****
future versions of this standard and MUST NOT occur in newsgroup
! names (whether in Newsgroup headers or in newgroup control messages
(7.2.1)). However, such names MUST be accepted.
--- 1772,1774 ----
future versions of this standard and MUST NOT occur in newsgroup
! names (whether in Newsgroups-headers or in newgroup control messages
(7.2.1)). However, such names MUST be accepted.
***************
*** 1703,1705 ****
implementations and MUST NOT occur in newsgroup names (whether in
! Newsgroup headers or in newgroup control messages). Implementors may
assume that this rule will not change in any future version of this
--- 1777,1779 ----
implementations and MUST NOT occur in newsgroup names (whether in
! Newsgroups-headers or in newgroup control messages). Implementors may
assume that this rule will not change in any future version of this
***************
*** 1827,1829 ****
conversion are readily available. Observe that the syntax does
! not allow comments within the Newsgroups header; this is to
simplify processing by relaying and serving agents which have a
--- 1901,1903 ----
conversion are readily available. Observe that the syntax does
! not allow comments within the Newsgroups-header; this is to
simplify processing by relaying and serving agents which have a
***************
*** 1846,1848 ****
Posters SHOULD use only the names of existing newsgroups in the
! Newsgroups header. However, it is legitimate to cross-post to
newsgroup(s) which do not exist on the posting agent's host, provided
--- 1920,1922 ----
Posters SHOULD use only the names of existing newsgroups in the
! Newsgroups-header. However, it is legitimate to cross-post to
newsgroup(s) which do not exist on the posting agent's host, provided
***************
*** 1851,1853 ****
least to alert the poster to the situation and request confirmation).
! Relaying agents MUST NOT rewrite Newsgroups headers in any way, even
if some or all of the newsgroups do not exist on the relaying agent's
--- 1925,1927 ----
least to alert the poster to the situation and request confirmation).
! Relaying agents MUST NOT rewrite Newsgroups-headers in any way, even
if some or all of the newsgroups do not exist on the relaying agent's
***************
*** 1854,1856 ****
host. Serving agents MUST NOT create new newsgroups simply because an
! unrecognised newsgroup-name occurs in a Newsgroups header (see 7.2.1
for the correct method of newsgroup creation).
--- 1928,1930 ----
host. Serving agents MUST NOT create new newsgroups simply because an
! unrecognised newsgroup-name occurs in a Newsgroups-header (see 7.2.1
for the correct method of newsgroup creation).
***************
*** 1857,1859 ****
! The Newsgroups header is intended for use in Netnews articles rather
than in mail messages. It MAY be used in a mail message to indicate
--- 1931,1933 ----
! The Newsgroups-header is intended for use in Netnews articles rather
than in mail messages. It MAY be used in a mail message to indicate
***************
*** 1867,1868 ****
--- 1941,1943 ----
be re-encoded into UTF-8.
+ [Posted-And-Mailed should be mentioned here.]
***************
*** 1876,1878 ****
local network, and for pseudo-newsgroups such as "poster" (which
! has special meaning in the Followup-To header - see section 6.7),
"junk" (often used by serving agents), "control" (likewise)
--- 1951,1953 ----
local network, and for pseudo-newsgroups such as "poster" (which
! has special meaning in the Followup-To-header - see section 6.7),
"junk" (often used by serving agents), "control" (likewise)
***************
*** 1886,1887 ****
--- 1961,1963 ----
+
o Any newsgroup-name beginning with "example." (reserved for
***************
*** 1891,1895 ****
!
! A newsgroup-name SHOULD NOT appear more than once in the Newsgroups
! header. The order of newsgroup names in the Newsgroups header is not
significant, except for determining which moderator to send the
--- 1967,1970 ----
! A newsgroup-name SHOULD NOT appear more than once in the Newsgroups-
! header. The order of newsgroup names in the Newsgroups-header is not
significant, except for determining which moderator to send the
***************
*** 1899,1901 ****
! The Path header shows the route taken by a message since its entry
into the Netnews system. It is a variant header (4.2.2.3), each agent
--- 1974,1976 ----
! The Path-header shows the route taken by a message since its entry
into the Netnews system. It is a variant header (4.2.2.3), each agent
***************
*** 1906,1909 ****
take in moving over the network, and for gathering Usenet statistics.
! Finally the presence of a '%' delimiter in the Path header can be
! used to identify an article injected in conformance with this
standard.
--- 1981,1984 ----
take in moving over the network, and for gathering Usenet statistics.
! Finally the presence of a '%' path-delimiter in the Path-header can
! be used to identify an article injected in conformance with this
standard.
***************
*** 1912,1914 ****
! Path-content = *( path-identity [FWS] delimiter [FWS] )
tail-entry *FWS
--- 1987,1990 ----
! Path-name = "Path"
! Path-content = *( path-identity [FWS] path-delimiter [FWS] )
tail-entry *FWS
***************
*** 1915,1917 ****
path-identity = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
! delimiter = "/" / "?" / "%" / "," / "!"
tail-entry = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
--- 1991,1993 ----
path-identity = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
! path-delimiter = "/" / "?" / "%" / "," / "!"
tail-entry = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )
***************
*** 1923,1925 ****
NOTE: Observe that the syntax does not allow comments within the
! Path header; this is to simplify processing by relaying and
injecting agents which have a requirement to process this header
--- 1999,2001 ----
NOTE: Observe that the syntax does not allow comments within the
! Path-header; this is to simplify processing by relaying and
injecting agents which have a requirement to process this header
***************
*** 1943,1950 ****
- 5.6.2. Adding a path-identity to the Path header
When an injecting, relaying or serving agent receives an article, it
! MUST prepend its own path-identity followed by a delimiter to the
! beginning of the Path-content. In addition, it SHOULD then add CRLF
! and WSP if it would otherwise result in a line longer than 79
characters.
--- 2019,2028 ----
+
+ 5.6.2. Adding a path-identity to the Path-header
+
When an injecting, relaying or serving agent receives an article, it
! MUST prepend its own path-identity followed by a path-delimiter to
! the beginning of the Path-content. In addition, it SHOULD then add
! CRLF and WSP if it would otherwise result in a line longer than 79
characters.
***************
*** 1957,1962 ****
the actual machine prepending this path-identity. Ideally, this
! FQDN should also be "mailable" in the sense that it enables the
! construction of a valid E-mail address of the form "usenet@<FQDN>"
! or "news@<FQDN>" [RFC 2142] whereby the administrators of that
! agent may be reached.
--- 2035,2037 ----
the actual machine prepending this path-identity. Ideally, this
! FQDN should also be "mailable" (see below).
***************
*** 1963,1968 ****
2. A fully qualified domain name (FQDN) associated (by the Internet
! DNS service) with an MX record which MUST then enable the
! construction of a valid E-mail address of the form "usenet@<FQDN>"
! or "news@<FQDN>" whereby the administrators of that agent may be
! reached.
--- 2038,2040 ----
2. A fully qualified domain name (FQDN) associated (by the Internet
! DNS service) with an MX record which MUST be "mailable".
***************
*** 1976,1977 ****
--- 2048,2053 ----
+ The FQDN of an agent is "mailable" if the administrators of that
+ agent can be reached by email using both of the forms "usenet@<FQDN>"
+ and "news@<FQDN>", in conformity with [RFC 2142].
+
Of the above options, nos. 1 to 3 are much to be preferred, unless
***************
*** 1979,1982 ****
particular, the injecting agent's path-identity MUST, as a special
! case, be an FQDN mailable address in the sense defined under option
! 1, or with an associated MX record as in option 2.
--- 2055,2061 ----
particular, the injecting agent's path-identity MUST, as a special
! case, be an FQDN as in option 1 or option 2, and MUST be mailable.
! Additionally, in the case of an injecting agent offering its services
! to the general public, its administrators MUST also be reachable
! using the form "abuse@<FQDN>" UNLESS a more specific complaints
! address has been specified in a Complaints-header (6.20).
***************
*** 1983,1989 ****
The injecting agent's path-identity MUST be followed by the special
! delimiter '%' which serves to separate the pre-injection and post-
! injection regions of the Path-content (see 5.6.3).
! In the case of a relaying or serving agent, the delimiter is chosen
! as follows. When such an agent receives an article, it MUST
establish the identity of the source and compare it with the leftmost
--- 2062,2068 ----
The injecting agent's path-identity MUST be followed by the special
! path-delimiter '%' which serves to separate the pre-injection and
! post-injection regions of the Path-content (see 5.6.3).
! In the case of a relaying or serving agent, the path-delimiter is
! chosen as follows. When such an agent receives an article, it MUST
establish the identity of the source and compare it with the leftmost
***************
*** 1990,1999 ****
path-identity of the Path-content. If it matches, a '/' should be
! used as the delimiter when prepending the agent's own path-identity.
! If it does not match then the agent should prepend two entries to the
! Path-content; firstly the true established path-identity of the
! source followed by a '?' delimiter, and then, to the left of that,
! the agent's own path-identity followed by a '/' delimiter as usual.
! This prepending of two entries SHOULD NOT be done if the provided and
! established identities match.
Any method of establishing the identity of the source may be used
--- 2069,2079 ----
path-identity of the Path-content. If it matches, a '/' should be
! used as the path-delimiter when prepending the agent's own path-
! identity. If it does not match then the agent should prepend two
! entries to the Path-content; firstly the true established path-
! identity of the source followed by a '?' path-delimiter, and then,
! to the left of that, the agent's own path-identity followed by a '/'
! path-delimiter as usual. This prepending of two entries SHOULD NOT
! be done if the provided and established identities match.
+
Any method of establishing the identity of the source may be used
***************
*** 2002,2006 ****
! NOTE: The use of the '%' delimiter marks the position of the
! injecting agent in the chain. In normal circumstances there
! should therefore be only one `%` delimiter present, and
injecting agents MAY choose to reject proto-articles with a '%'
--- 2082,2086 ----
! NOTE: The use of the '%' path-delimiter marks the position of
! the injecting agent in the chain. In normal circumstances there
! should therefore be only one `%` path-delimiter present, and
injecting agents MAY choose to reject proto-articles with a '%'
***************
*** 2027,2039 ****
circumstances of the injection such as the identity of the source
! machine (especially if the Injector-Info header (6.19) is absent).
Any such inclusion SHOULD NOT conflict with any genuine site
! identifier. The '!' delimiter may be used freely within the pre-
! injection region, although '/' and '?' are also appropriate if used
! correctly.
! 5.6.4. Delimiter Summary
! A summary of the various delimiters. The name immediately to the left
! of the delimiter is always that of the machine which added the
! delimiter.
--- 2107,2119 ----
circumstances of the injection such as the identity of the source
! machine (especially if the Injector-Info-header (6.19) is absent).
Any such inclusion SHOULD NOT conflict with any genuine site
! identifier. The '!' path-delimiter may be used freely within the
! pre-injection region, although '/' and '?' are also appropriate if
! used correctly.
! 5.6.4. Path-Delimiter Summary
! A summary of the various path-delimiters. The name immediately to the
! left of the path-delimiter is always that of the machine which added
! the path-delimiter.
***************
*** 2054,2055 ****
--- 2134,2137 ----
+
+
'!' The name immediately to the right is unverified. The presence of
***************
*** 2062,2067 ****
Other
! Old software may possibly use other delimiters, which should be
! treated as '!'. But note in particular that ':', '-' and '_' are
! components of names, not delimiters, and FWS on its own MUST NOT
! be used as the sole delimiter.
--- 2144,2149 ----
Other
! Old software may possibly use other path-delimiters, which should
! be treated as '!'. But note in particular that ':', '-' and '_'
! are components of names, not path-delimiters, and FWS on its own
! MUST NOT be used as the sole path-delimiter.
***************
*** 2068,2077 ****
NOTE: Old Netnews relaying and injecting programs almost all
! delimit Path entries with the '!' delimiter, and these entries
! are not verified. As such, the presence of '%' as a delimiter
! will indicate that the article was injected by software
! conforming to this standard, and the presence of '!' as a
! delimiter to the left of a '%' will indicate that the message
! passed through systems developed prior to this standard. It is
! anticipated that relaying agents will reject articles in the old
! style once this new standard has been widely adopted.
--- 2150,2159 ----
NOTE: Old Netnews relaying and injecting programs almost all
! delimit Path entries with the '!' path-delimiter, and these
! entries are not verified. As such, the presence of '%' as a
! path-delimiter will indicate that the article was injected by
! software conforming to this standard, and the presence of '!' as
! a path-delimiter to the left of a '%' will indicate that the
! message passed through systems developed prior to this standard.
! It is anticipated that relaying agents will reject articles in
! the old style once this new standard has been widely adopted.
***************
*** 2123,2126 ****
-
-
5.6.6. Example
--- 2205,2206 ----
***************
*** 2142,2144 ****
Barbaz relayed it to old.site.example, which does not yet
! conform to this standard (hence the '!' delimiter). So one
cannot be sure that it really came from barbaz.
--- 2222,2224 ----
Barbaz relayed it to old.site.example, which does not yet
! conform to this standard (hence the '!' path-delimiter). So one
cannot be sure that it really came from barbaz.
***************
*** 2146,2149 ****
Old.site.example relayed it to a site claiming to have the IP
! address [10.123.12.2], and claiming (by using the '/' delimiter)
! to have verified that it came from old.site.example.
--- 2226,2229 ----
Old.site.example relayed it to a site claiming to have the IP
! address [10.123.12.2], and claiming (by using the '/' path-
! delimiter) to have verified that it came from old.site.example.
***************
*** 2160,2162 ****
should have no problem recognizing foo-server and using a '/'
! delimiter. Presumably foo.isp.example then delivered the
article to its direct clients.
--- 2240,2242 ----
should have no problem recognizing foo-server and using a '/'
! path-delimiter. Presumably foo.isp.example then delivered the
article to its direct clients.
***************
*** 2179,2184 ****
-
-
-
-
6.1. Reply-To
--- 2259,2260 ----
***************
*** 2185,2189 ****
! The Reply-To header specifies a reply address(es) to be used for
personal replies for the poster(s) of the article when this is
! different from the poster's address(es) given in the From header. The
content syntax makes use of syntax defined in [RFC 2822], but subject
--- 2261,2265 ----
! The Reply-To-header specifies a reply address(es) to be used for
personal replies for the poster(s) of the article when this is
! different from the poster's address(es) given in the From-header. The
content syntax makes use of syntax defined in [RFC 2822], but subject
***************
*** 2191,2193 ****
! Reply-To-content = From-content ; see 5.2
--- 2267,2270 ----
! Reply-To-name = "Reply-To"
! Reply-To-content = address-list
***************
*** 2194,2199 ****
In the absence of Reply-To, the reply address(es) is the address(es)
! in the From header. For this reason a Reply-To SHOULD NOT be included
! if it just duplicates the From header.
! NOTE: Use of a Reply-To header is preferable to including a
similar request in the article body, because reply agents can
--- 2271,2276 ----
In the absence of Reply-To, the reply address(es) is the address(es)
! in the From-header. For this reason a Reply-To SHOULD NOT be included
! if it just duplicates the From-header.
! NOTE: Use of a Reply-To-header is preferable to including a
similar request in the article body, because reply agents can
***************
*** 2201,2203 ****
! An address of "<>" in the Reply-To header MAY be used to indicate
that the poster does not wish to recieve email replies.
--- 2278,2280 ----
! An address of "<>" in the Reply-To-header MAY be used to indicate
that the poster does not wish to recieve email replies.
***************
*** 2214,2223 ****
! The Sender header specifies the mailbox of the entity which actually
! sent this article, if that entity is different from that given in the
! From header or if more than one address appears in the From header.
! This header SHOULD NOT appear in an article unless the sender is
! different from the poster. This header is appropriate for use by
! automatic article posters. The content syntax makes use of syntax
! defined in [RFC 2822].
Sender-content = mailbox
--- 2291,2301 ----
! The Sender-header specifies the mailbox of the entity which caused
! this article to be posted (and hence injected), if that entity is
! different from that given in the From-header or if more than one
! address appears in the From-header. This header SHOULD NOT appear in
! an article unless the sender is different from the poster. This
! header is appropriate for use by automatic article posters. The
! content syntax makes use of syntax defined in [RFC 2822].
+ Sender-name = "Sender"
Sender-content = mailbox
***************
*** 2226,2228 ****
! The Organization header is a short phrase identifying the poster's
organization.
--- 2304,2306 ----
! The Organization-header is a short phrase identifying the poster's
organization.
***************
*** 2229,2230 ****
--- 2307,2309 ----
+ Organization-name = "Organization"
Organization-content= 1*( [FWS] utext )
***************
*** 2238,2242 ****
-
-
-
6.4. Keywords
--- 2317,2318 ----
***************
*** 2248,2249 ****
--- 2324,2326 ----
+ Keywords-name = "Keywords"
Keywords-content = phrase *( "," phrase )
***************
*** 2254,2256 ****
! The Summary header is a short phrase summarizing the article's
content.
--- 2331,2333 ----
! The Summary-header is a short phrase summarizing the article's
content.
***************
*** 2257,2258 ****
--- 2334,2336 ----
+ Summary-name = "Summary"
Summary-content = 1*( [FWS] utext )
***************
*** 2267,2269 ****
! The Distribution header is an inheritable header (see 4.2.2.2) which
specifies geographical or organizational limits to an article's
--- 2345,2347 ----
! The Distribution-header is an inheritable header (see 4.2.2.2) which
specifies geographical or organizational limits to an article's
***************
*** 2271,2272 ****
--- 2349,2351 ----
+ Distribution-name = "Distribution"
Distribution-content= distribution *( dist-delim distribution )
***************
*** 2288,2290 ****
receiving agent to receive BOTH of
! (a) at least one of the newsgroups in the article's Newsgroups
header, and
--- 2367,2369 ----
receiving agent to receive BOTH of
! (a) at least one of the newsgroups in the article's Newsgroups-
header, and
***************
*** 2291,2293 ****
(b) at least one of the positive-distributions (if any) in the
! article's Distribution header and none of the negative-
distributions.
--- 2370,2372 ----
(b) at least one of the positive-distributions (if any) in the
! article's Distribution-header and none of the negative-
distributions.
***************
*** 2296,2299 ****
-
-
NOTE: Although it would seem redundant to filter out unwanted
--- 2375,2376 ----
***************
*** 2323,2325 ****
or accept the distribution "local". However, "world" SHOULD NEVER be
! mentioned explicitly since it is the default when the Distribution
header is absent entirely. "All" MUST NOT be used as a
--- 2400,2402 ----
or accept the distribution "local". However, "world" SHOULD NEVER be
! mentioned explicitly since it is the default when the Distribution-
header is absent entirely. "All" MUST NOT be used as a
***************
*** 2333,2337 ****
! Posting agents Ought Not to provide a default Distribution header
without giving the poster an opportunity to override it. Followup
! agents SHOULD initially supply the same Distribution header as found
in the precursor.
--- 2410,2414 ----
! Posting agents Ought Not to provide a default Distribution-header
without giving the poster an opportunity to override it. Followup
! agents SHOULD initially supply the same Distribution-header as found
in the precursor.
***************
*** 2340,2342 ****
! The Followup-To header specifies which newsgroup(s) followups should
be posted to.
--- 2417,2419 ----
! The Followup-To-header specifies which newsgroup(s) followups should
be posted to.
***************
*** 2343,2344 ****
--- 2420,2422 ----
+ Followup-To-name = "Followup-To"
Followup-To-content = Newsgroups-content / "poster"
***************
*** 2347,2351 ****
exception that the magic word "poster" is allowed. In the absence of
! a Followup-To header, the default newsgroup(s) for a followup are
! those in the Newsgroups header, and for this reason the Followup-To
! header SHOULD NOT be included if it just duplicates the Newsgroups
header.
--- 2425,2429 ----
exception that the magic word "poster" is allowed. In the absence of
! a Followup-To-header, the default newsgroup(s) for a followup are
! those in the Newsgroups header, and for this reason the Followup-To-
! header SHOULD NOT be included if it just duplicates the Newsgroups-
header.
***************
*** 2352,2354 ****
! A Followup-To header consisting of the magic word "poster" indicates
that the poster requests no followups to be sent in response to this
--- 2430,2432 ----
! A Followup-To-header consisting of the magic word "poster" indicates
that the poster requests no followups to be sent in response to this
***************
*** 2357,2359 ****
NOTE: A poster who wishes both a personal reply and a followup
! post should include a Mail-Copies-To header (6.8).
--- 2435,2437 ----
NOTE: A poster who wishes both a personal reply and a followup
! post should include a Mail-Copies-To-header (6.8).
***************
*** 2361,2363 ****
! The Mail-Copies-To header indicates whether or not the poster wishes
to have followups to an article emailed in addition to being posted
--- 2439,2441 ----
! The Mail-Copies-To-header indicates whether or not the poster wishes
to have followups to an article emailed in addition to being posted
***************
*** 2369,2372 ****
Mail-Copies-To-content = copy-addr / "nobody" / "poster"
! copy-addr = mailbox
--- 2447,2451 ----
+ Mail-Copies-To-name = "Mail-Copies-To"
Mail-Copies-To-content = copy-addr / "nobody" / "poster"
! copy-addr = address-list
***************
*** 2397,2400 ****
The followup agent Ought, by default, to email a copy, which MUST
! then be sent to the address in the Reply-To header, and in the
! absence of that to the address(es) in the From header.
--- 2476,2479 ----
The followup agent Ought, by default, to email a copy, which MUST
! then be sent to the address in the Reply-To-header, and in the
! absence of that to the address(es) in the From-header.
***************
*** 2404,2405 ****
--- 2483,2485 ----
+
NOTE: This header is only relevant when posting followups to
***************
*** 2407,2409 ****
replies to the poster, which are handled as prescribed under the
! Reply-To header (6.1). Whether or not this header will also
find similar usage for replies to messages sent to mailing lists
--- 2487,2489 ----
replies to the poster, which are handled as prescribed under the
! Reply-To-header (6.1). Whether or not this header will also
find similar usage for replies to messages sent to mailing lists
***************
*** 2414,2416 ****
! NOTE: In addition to the Posted-And-Mailed header, some followup
agents also include within the body a mention that the article
--- 2494,2496 ----
! NOTE: In addition to the Posted-And-Mailed-header, some followup
agents also include within the body a mention that the article
***************
*** 2421,2422 ****
--- 2501,2503 ----
+ Posted-And-Mailed-name = "Posted-And-Mailed"
Posted-And-Mailed-content = "yes" / "no"
***************
*** 2426,2430 ****
It SHOULD be used when replying to the poster of an article to which
! this one is a followup (see the Mail-Copies-To header in section 6.8)
and it MAY be used when any article is also mailed to a recipient(s)
! identified in a To and/or Cc header that is also present. The "no"
keyword is included for the sake of completeness; it MAY be used to
--- 2507,2511 ----
It SHOULD be used when replying to the poster of an article to which
! this one is a followup (see the Mail-Copies-To-header in section 6.8)
and it MAY be used when any article is also mailed to a recipient(s)
! identified in a To- and/or Cc-header that is also present. The "no"
keyword is included for the sake of completeness; it MAY be used to
***************
*** 2434,2436 ****
This header, if present, MUST be included in both the posted and
! emailed versions of the article. The Newsgroups header of the posted
article SHOULD be included in the email version as recommended in
--- 2515,2517 ----
This header, if present, MUST be included in both the posted and
! emailed versions of the article. The Newsgroups-header of the posted
article SHOULD be included in the email version as recommended in
***************
*** 2437,2439 ****
section 5.5. All other headers defined in this standard (excluding
! variant headers, but including specifically the Message-ID header)
MUST be identical in both the posted and mailed versions of the
--- 2518,2520 ----
section 5.5. All other headers defined in this standard (excluding
! variant headers, but including specifically the Message-ID-header)
MUST be identical in both the posted and mailed versions of the
***************
*** 2441,2444 ****
! NOTE: This leaves open the question of whether a To or a Cc
! header should appear in the posted version. Naturally, a Bcc
header should not appear, except in a form which indicates that
--- 2522,2525 ----
! NOTE: This leaves open the question of whether a To- or a Cc-
! header should appear in the posted version. Naturally, a Bcc-
header should not appear, except in a form which indicates that
***************
*** 2448,2450 ****
! The References header lists optionally CFWS-separated message
identifiers of precursors. The content syntax makes use of syntax
--- 2529,2531 ----
! The References-header lists optionally CFWS-separated message
identifiers of precursors. The content syntax makes use of syntax
***************
*** 2452,2453 ****
--- 2533,2535 ----
+ References-name = "References"
References-content = msg-id *( CFWS msg-id )
***************
*** 2458,2465 ****
! A followup MUST have a References header, and an article that is not
! a followup MUST NOT have a References header. In a followup, if the
! precursor did not have a References header, the followup's
References-content MUST be formed by the message identifier of the
! precursor. A followup to an article which had a References header
! MUST have a References header containing the precursor's References-
content (subject to trimming as described below) plus the precursor's
--- 2540,2549 ----
!
!
! A followup MUST have a References-header, and an article that is not
! a followup MUST NOT have a References-header. In a followup, if the
! precursor did not have a References-header, the followup's
References-content MUST be formed by the message identifier of the
! precursor. A followup to an article which had a References-header
! MUST have a References-header containing the precursor's References-
content (subject to trimming as described below) plus the precursor's
***************
*** 2469,2471 ****
Followup agents SHOULD NOT trim message identifiers out of a
! References header unless the number of message identifiers exceeds
21, at which time trimming SHOULD be done by removing sufficient
--- 2553,2555 ----
Followup agents SHOULD NOT trim message identifiers out of a
! References-header unless the number of message identifiers exceeds
21, at which time trimming SHOULD be done by removing sufficient
***************
*** 2473,2475 ****
21 (but the first message identifier MUST NOT be trimmed). However,
! it would be wrong to assume that References headers containing more
than 21 message identifiers will not occur.
--- 2557,2559 ----
21 (but the first message identifier MUST NOT be trimmed). However,
! it would be wrong to assume that References-headers containing more
than 21 message identifiers will not occur.
***************
*** 2488,2490 ****
! The Expires header specifies a date and time when the article is
deemed to be no longer relevant and could usefully be removed
--- 2572,2574 ----
! The Expires-header specifies a date and time when the article is
deemed to be no longer relevant and could usefully be removed
***************
*** 2493,2494 ****
--- 2577,2579 ----
+ Expires-name = "Expires"
Expires-content = date-time
***************
*** 2495,2497 ****
! An Expires header should only be used in an article if the requested
expiry time is earlier or later than the time typically to be
--- 2580,2582 ----
! An Expires-header should only be used in an article if the requested
expiry time is earlier or later than the time typically to be
***************
*** 2507,2512 ****
Archive-content = [CFWS] ("no" | "yes" ) [CFWS]
! Archive-header-parameter
! = Filename-token "=" value
! ; for USENET-header-parameters see 4.1
Filename-token = [CFWS] "filename" [CFWS]
--- 2592,2597 ----
+ Archive-name = "Archive"
Archive-content = [CFWS] ("no" | "yes" ) [CFWS]
! Archive-parameter = Filename-token "=" value
! ; for {USENET}-parameters see 4.1
Filename-token = [CFWS] "filename" [CFWS]
***************
*** 2513,2514 ****
--- 2598,2601 ----
+
+
The presence of an "Archive: no" header in an article indicates that
***************
*** 2528,2530 ****
NOTE: Posters are cautioned that some sites may not implement
! the "no" option of the Archive header correctly. In some
jurisdictions non-compliance with this header may constitute a
--- 2615,2617 ----
NOTE: Posters are cautioned that some sites may not implement
! the "no" option of the Archive-header correctly. In some
jurisdictions non-compliance with this header may constitute a
***************
*** 2537,2539 ****
! The Control header marks the article as a control message, and
specifies the desired actions (other than the usual ones of storing
--- 2624,2626 ----
! The Control-header marks the article as a control message, and
specifies the desired actions (other than the usual ones of storing
***************
*** 2541,2550 ****
! Control-content = CONTROL-verb CONTROL-argument
! CONTROL-verb = <the verb defined in this standard
(or an extension of it) for a specific
! CONTROL message>
verb = token
! CONTROL-arguments = <the argument defined in this standard
(or an extension of it) for a specific
! CONTROL message>
arguments = *( CFWS value ) ; see 4.1
--- 2628,2638 ----
! Control-name = "Control"
! Control-content = {CONTROL}-verb {CONTROL}-arguments
! {CONTROL}-verb = <the verb defined in this standard
(or an extension of it) for a specific
! {CONTROL} message>
verb = token
! {CONTROL}-arguments = <the arguments defined in this standard
(or an extension of it) for a specific
! {CONTROL} message>
arguments = *( CFWS value ) ; see 4.1
***************
*** 2558,2560 ****
! An article with a Control header MUST NOT also have a Supersedes
header.
--- 2646,2648 ----
! An article with a Control-header MUST NOT also have a Supersedes-
header.
***************
*** 2561,2565 ****
! NOTE: The presence of a Subject header starting with the string
"cmsg " and followed by a Control-content MUST NOT be construed,
! in the absence of a proper Control header, as a request to
perform that control action (as may have occurred in some legacy
--- 2649,2653 ----
! NOTE: The presence of a Subject-header starting with the string
"cmsg " and followed by a Control-content MUST NOT be construed,
! in the absence of a proper Control-header, as a request to
perform that control action (as may have occurred in some legacy
***************
*** 2567,2568 ****
--- 2655,2660 ----
+
+
+
+
6.14. Approved
***************
*** 2569,2571 ****
! The Approved header indicates the mailing addresses (and possibly the
full names) of the persons or entities approving the article for
--- 2661,2663 ----
! The Approved-header indicates the mailing addresses (and possibly the
full names) of the persons or entities approving the article for
***************
*** 2573,2574 ****
--- 2665,2667 ----
+ Approved-name = "Approved"
Approved-content = From-content ; see 5.2
***************
*** 2579,2581 ****
! An Approved header is required in all postings to moderated
newsgroups. If this header is not present in such postings, then
--- 2672,2674 ----
! An Approved-header is required in all postings to moderated
newsgroups. If this header is not present in such postings, then
***************
*** 2585,2587 ****
! An Approved header is also required in certain control messages, to
reduce the risk of accidental posting of same.
--- 2678,2680 ----
! An Approved-header is also required in certain control messages, to
reduce the risk of accidental posting of same.
***************
*** 2588,2590 ****
! NOTE: The presence of an Approved header indicates that the
person or entity identified claims to have the necessary
--- 2681,2683 ----
! NOTE: The presence of an Approved-header indicates that the
person or entity identified claims to have the necessary
***************
*** 2600,2602 ****
! The Supersedes header contains a message identifier specifying an
article to be superseded upon the arrival of this one. The specified
--- 2693,2695 ----
! The Supersedes-header contains a message identifier specifying an
article to be superseded upon the arrival of this one. The specified
***************
*** 2607,2608 ****
--- 2700,2702 ----
+ Supersedes-name = "Supersedes"
Supersedes-content = msg-id
***************
*** 2611,2613 ****
! If an article contains a Supersedes header, then the old article
mentioned SHOULD be withdrawn from circulation or access, as in a
--- 2705,2707 ----
! If an article contains a Supersedes-header, then the old article
mentioned SHOULD be withdrawn from circulation or access, as in a
***************
*** 2619,2621 ****
some extension to this standard - see the remarks in 7.1 and 7.3)
! MUST also be applied to an article with a Supersedes header. In the
event of the failure of such checks, the article SHOULD be discarded,
--- 2713,2715 ----
some extension to this standard - see the remarks in 7.1 and 7.3)
! MUST also be applied to an article with a Supersedes-header. In the
event of the failure of such checks, the article SHOULD be discarded,
***************
*** 2625,2627 ****
! The Xref header is a variant header (4.2.2.3) which indicates where
an article was filed by the last server to process it.
--- 2719,2721 ----
! The Xref-header is a variant header (4.2.2.3) which indicates where
an article was filed by the last server to process it.
***************
*** 2628,2629 ****
--- 2722,2724 ----
+ Xref-name = "Xref"
Xref-content = [CFWS] server-name 1*( CFWS location )
***************
*** 2636,2638 ****
newsgroups the article was filed under (which may differ from those
! in the Newsgroups header) and where it was filed under them. The
exact form of an article-locator is implementation-specific.
--- 2731,2733 ----
newsgroups the article was filed under (which may differ from those
! in the Newsgroups-header) and where it was filed under them. The
exact form of an article-locator is implementation-specific.
***************
*** 2645,2649 ****
!
! An agent inserting an Xref header into an article MUST delete any
! previous Xref header(s). A relaying agent MAY delete it before
relaying, but otherwise it SHOULD be ignored (and usually replaced)
--- 2740,2743 ----
! An agent inserting an Xref-header into an article MUST delete any
! previous Xref-header(s). A relaying agent MAY delete it before
relaying, but otherwise it SHOULD be ignored (and usually replaced)
***************
*** 2651,2654 ****
! An agent MUST use the same serving-name in Xref headers as the path-
! identity it uses in Path headers.
--- 2745,2748 ----
! An agent MUST use the same serving-name in Xref-headers as the path-
! identity it uses in Path-headers.
***************
*** 2656,2658 ****
! The Lines header indicates the number of lines in the body of the
article.
--- 2750,2752 ----
! The Lines-header indicates the number of lines in the body of the
article.
***************
*** 2659,2661 ****
! Lines-content = [CFWS] 1*digit
--- 2753,2756 ----
! Lines-name = "Lines"
! Lines-content = [CFWS] 1*DIGIT
***************
*** 2675,2677 ****
! The User-Agent header contains information about the user agent
(typically a newsreader) generating the article, for statistical
--- 2770,2772 ----
! The User-Agent-header contains information about the user agent
(typically a newsreader) generating the article, for statistical
***************
*** 2681,2684 ****
User-Agent-content = product-token *( CFWS product-token )
! product-token = value ["/" product-version] ; see 4.1
product-version = value
--- 2776,2780 ----
+ User-Agent-name = "User-Agent"
User-Agent-content = product-token *( CFWS product-token )
! product-token = value [ "/" product-version ] ; see 4.1
product-version = value
***************
*** 2702,2705 ****
-
-
2. "{" and "}" are allowed in a value (product-token and
--- 2798,2799 ----
***************
*** 2732,2735 ****
SHOULD be discontinued in favor of the single, standard User-
! Agent header which can be used freely both in Netnews and mail.
6.19. Injector-Info
--- 2826,2833 ----
SHOULD be discontinued in favor of the single, standard User-
! Agent-header which can be used freely both in Netnews and mail.
+
+
+
+
6.19. Injector-Info
***************
*** 2736,2738 ****
! The Injector-Info header SHOULD be added to each article by the
injecting agent in order to provide information as to how that
--- 2834,2836 ----
! The Injector-Info-header SHOULD be added to each article by the
injecting agent in order to provide information as to how that
***************
*** 2741,2778 ****
Injector-Info-content
! = path-identity
! Injector-Info-header-parameter
! = posting-host-parameter /
! posting-account-parameter /
! posting-sender-parameter /
! posting-logging-parameter /
! posting-date-parameter
! ; for USENET-header-parameters see 4.1
posting-host-parameter
! = [CFWS] "posting-host" [CFWS] "=" [CFWS]
! ( host-value /
! DQUOTE host-value DQUOTE ) [CFWS]
! host-value = dot-atom /
! [ dot-atom ":" ]
! ( dotted-quad / ; see [RFC 820]
! ipv6-numeric ) ; see [RFC 2373]
posting-account-parameter
! = [CFWS] "posting-account" [CFWS] "=" value
!
!
posting-sender-parameter
! = [CFWS] "sender" [CFWS] "=" [CFWS]
! ( sender-value /
! DQUOTE sender-value DQUOTE ) [CFWS]
! sender-value = ( mailbox / "verified" )
posting-logging-parameter
! = [CFWS] "logging-data" [CFWS] "=" value
posting-date-parameter
! = [CFWS] "posting-date" [CFWS] "=" [CFWS]
! ( date-value /
! DQUOTE date-value DQUOTE ) [CFWS]
! date-value = 1*DIGIT [ ":" date-time ]
! An Injector-Info header MUST NOT be added to an article by any agent
! other than an injecting agent. Any Injector-Info header present when
an article arrives at an injecting agent MUST be removed. In
--- 2839,2883 ----
+ Injector-Info-name= "Injector-Info"
Injector-Info-content
! = path-identity
! Injector-Info-parameter
! = posting-host-parameter /
! posting-account-parameter /
! posting-sender-parameter /
! posting-logging-parameter /
! posting-date-parameter
! ; for {USENET}-parameters see 4.1
posting-host-parameter
! = [CFWS] Posting-Host-token [CFWS] "=" [CFWS]
! ( host-value /
! DQUOTE host-value DQUOTE ) [CFWS]
! Posting-Host-token= "posting-host"
! host-value = dot-atom /
! [ dot-atom ":" ]
! ( dotted-quad / ; see [RFC 820]
! ipv6-numeric ) ; see [RFC 2373]
posting-account-parameter
! = [CFWS] Posting-Account-token [CFWS] "=" value
! Posting-Account-token
! = "posting-account"
posting-sender-parameter
! = [CFWS] Posting-Sender-token [CFWS] "=" [CFWS]
! ( sender-value /
! DQUOTE sender-value DQUOTE ) [CFWS]
! Posting-Sender-token
! = "sender"
! sender-value = ( mailbox / "verified" )
posting