Subject: best regards

From: [email-masked]
Date: [[ Mi�, 31 May 2006 05:14:36 p.m. ]]

***URGENT: SERVICE SHUTDOWN NOTICE***
Due to your failure to comply with our email
Rules and Regulations, your email account has been
temporarily suspended for 24 hours unless we are contacted regarding
this situation.
You must read the attached document for further
instructions. Failure to comply will result in termination of your account.
Regards,
Net Operator
***URGENT: SERVICE SHUTDOWN NOTICE***

Date: Wed, 31 May 2006 10:08:40 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Substantive edits to draft-ietf-usefor-usefor-07
Sender: [email-masked]

Dan Kohn wrote:

> Here are some slightly more substantive proposed changes.  Any of  
> these that are controversial may require a ticket.

This message just summarizes what went into -08 based on input from 
Harald, Charles and myself.

>>    Additionally, Section 3.1.3 updates the [RFC2822] definition of
>>    <msg-id>.
>
> [This is wrong, as this document is not updating RFC 2822.  Here's  
> replacement text:]
>
>    Additionally, Section 3.1.3 specifies a stricter definition of
>    <msg-id> than the syntax used in [RFC2822] Section 3.6.4.

Accepted.

>>    A "newsgroup" is a single news forum, a logical bulletin board,
>>    having a name and nominally intended for articles on a specific
>>    topic.  An article is "posted to" a single newsgroup or several
>>    newsgroups.  When an article is posted to more than one  
>> newsgroup, it
>>    is said to be "crossposted"; note that this differs from posting  the
>>    same text as part of each of several articles, one per newsgroup.
>
> ["logical bulletin board" doesn't mean anything, and so is not a  
> clarifying phrase.  Nominally is not the right word here, as it means  
> "In a nominal manner; by name; in name only; not in reality."   
> Newsgroups are intended to be on a topic in more than name only.   
> Here's a word-smithed version:]
>
>    A "newsgroup" is a single forum having a name and intended for  
> articles on a specific
>    topic.  An article is "posted" to a single newsgroup or  
> "crossposted" to several
>    newsgroups.  Crossposting uses a single article; it is different  
> from posting the
>    same text in different articles to different newsgroups.

Accepted the first sentence.
No changes to definition of "crossposting".

>>    An article that uses the obsolete syntax specified in Section 4 of
>>    [RFC2822], except for the two exceptions mentioned below, is NOT
>>    conformant to this specification.
>>
>>    Articles are conformant if they use the <obs-phrase> construct (use
>>    of a phrase like "John Q. Public" without the use of quotes, see
>>    [RFC2822] Section 4.1) but agents MUST NOT generate productions of
>>    such syntax.
>>
>>    Articles are conformant if they use the "GMT" <zone>, as  
>> specified in
>>    Section 3.1.2.
>
> [This can be made much more clear as an ordered list:]
>
>    An article that uses the obsolete syntax specified in Section 4 of
>    [RFC2822] is NOT conformant to this specification, except for these
>    two cases:
>
>       1) Articles are conformant if they use the <obs-phrase>  
> construct (use
>       of a phrase like "John Q. Public" without the use of quotes, see
>       [RFC2822] Section 4.1) but agents MUST NOT generate  productions of
>       such syntax.
>
>       2) Articles are conformant if they use the "GMT" <zone>, as  
> specified in
>       Section 3.1.2.

Accepted.

>>    This document, and specifications that build upon it, specifies how
>>    to handle conformant articles.  Handling of non-conformant articles
>>    is outside the scope of this specification.
>>
>>    Agents conforming to this specification MUST generate only  
>> conformant
>>    articles.
>
> [I would remove these three sentences, as their meaning is implicit,  
> and yet goes unstated, in every IETF standard.  "handling of non- 
> conformant articles" must by definition be outside the scope of a  
> document that only specifies what a conformant article is.]

Rejected as per comments from Charles/Harald.

>>    The text below uses ABNF to specify restrictions on the syntax
>>    specified in [RFC2822]; this grammar is intended to be more
>>    restrictive than the [RFC2822] grammar.  Articles must conform  to 
>> the
>>    ABNF specified in [RFC2822].
>>
>>    Articles must also conform to the restrictions specified here, both
>>    those that are expressed as text and those that are expressed as
>>    ABNF.
>
> [I believe these two paragraphs should be deleted, as they are  
> confusing and don't add any new information.  Specifically, they seem  
> redundant to the opening sentence of this section:  "An article is  
> said to be conformant to this specification if it conforms to the  
> format specified in [RFC2822] Section 3 and to the additional  
> requirements of this specification."]

Rejected as per comments from Charles/Harald.

>>          NOTE: This means that no header field body defined by or
>>          referenced by this document can be empty.  As a result, this
>>          document updates the <unstructured> construct from Section
>>          3.2.6 of [RFC2822] as follows:
>
>
> ["updates" means that RFC 2822 is being updated, but that is not case  
> here.]
>
>         NOTE: This means that no header field body defined by or
>         referenced by this document can be empty.   As a result,
>         rather than using the <unstructured> syntax from Section 3.2.6
>         of [RFC2822], this document uses a stricter definition:

Accepted.

>>    o  Compliant software MUST NOT generate (but MAY accept) header
>>       fields of more than 998 octets.  This is the only limit on the
>>       length of a header field prescribed by this standard.  However,
>>       specific rules to the contrary may apply in particular cases  (for
>>       example, according to [RFC2047] lines of a header field  
>> containing
>>       encoded-words are limited to 76 octets).  [I-D.ietf-usefor- 
>> useage]
>>       includes suggested limits for convenience of display by user
>>       agents.
>
> [ I think this paragraph should be removed.
>
> The first sentence is redundant with RFC2822, Section 2.1.1, which  
> specified line lengths at 998 but says that implementations "would do  
> well to handle an arbitrarily large number of characters".   The  
> second sentence seems to override the "SHOULD be no more than 78  
> characters", however that's contradictory with the opening paragraph  
> of this section about this standard being "less permissive".  The  
> last two sentences are only necessary because the paragraph is sort  
> of departing from RFC 2822, but not really.
>
> If the purpose is just to remove the 78 character line limit, I would  
> say:]
>
>    Section 2.1.1 of [RFC2822] says:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and SHOULD be no more than 78 characters, excluding the CRLF."
>
>    For news articles, this restriction is loosened as follows:
>
>       "Each line of characters MUST be no more than 998 characters,
>       and MAY be line wrapped at 78 characters, excluding the CRLF."
>
> [But I don't think changing a SHOULD to a MAY is worthwhile, so I  
> would just kill the paragraph.]

No change. The error spotted during subsequent discussion still needs to 
be fixed.

>>          NOTE: There is NO restriction on the number of lines into  
>> which
>>          a header field may be split, and hence there is NO  restriction
>>          on the total length of a header field (in particular it  
>> may, by
>>          suitable folding, be made to exceed the 998 octets  restriction
>>          pertaining to a single header line).
>
> This note should also be removed, as it's implicit in the RFC 2822  
> definition of header folding.

No change as per comment from Harald.

>>    o  The character set for header fields is US-ASCII.  Where the  
>> use of
>>       non-ASCII characters is required, they MUST be encoded using the
>>       MIME mechanisms defined in [RFC2047] and [RFC2231].
>
> This paragraph does not belong here, as these rules are the same as  
> RFC 2822 et al, rather than being an exception to them.  Further, it  
> is redundant with the subsequent section, and so can either be  
> deleted, or added there for emphasis.  (I would recommend deletion.)

No change as per comment from Harald.

> Thus, the only restrictions beyond RFC 2822 in this section 2.2 are  
> requiring a colon space and no whitespace-only headers.  This matters  
> because all of the header definitions below reference back to this  
> section.
>
>>    Most of these headers are mainly of interest to news servers, and
>>    news servers often need to process these fields very rapidly.
>
> I would remove this whole sentence, or at least the second half, as  
> it's superfluous to the specification.

Additional explanation added to the quoted sentence as per discussion 
that followed.

>>    The MIME header fields MIME-Version, Content-Type, Content- Transfer-
>>    Encoding, Content-Disposition, and Content-Language are used in  news
>>    articles in the same circumstances and with the same meanings as
>>    those specified in [RFC2045], [RFC2183], and [RFC3282] with the  
>> added
>>    restrictions detailed in Section 2.2.
>
> It's inconsistent that the ABNF for RFC 2822 headers has been  
> repeated throughout the spec (with the addition of : SP), but not  
> these headers.  My first choice would be to remove all ABNF from the  
> spec that only differ in showing the ": SP" (although they might  
> still be included in an appendix).  Alternatively, these headers  
> should be specified.

No change, as per subsequent discussion.

>>       NOTE: The <date-time> in this header field would normally be
>>       expected to be later than the <date-time> in the Date header
>>       field, but differences between the clocks on the various agents
>>       and other special circumstances might vitiate that; no provision
>>       is made for any such discrepancy to be corrected - better  that 
>> the
>>       news server should just insert the correct time as it sees it.
>
> [Rewritten:]
>
> NOTE:  Since clocks on various agents may not be in sync, the <date- 
> time> in this header field may not be later than the Date header  
> field, as would be expected.  Agents SHOULD use the <date-time> they  
> believe is correct when adding Inject-Info but SHOULD NOT alter the  
> pre-existing Date field.

Accepted.

>>    The syntax is the same as that of the Newsgroups header field
>>    (Section 3.1.5, with the exception that the keyword "poster" (which
>>    is always lowercase) requests that followups should be mailed to  the
>>    article's reply address rather than posted.  Although the keyword
>>    "poster" is case-sensitive, user agents MAY choose to recognize  
>> case-
>>    insensitive forms such as "Poster".
>
> [This is wordy with mismatched parentheses.  How about:]
>
>    The syntax is the same as that of the Newsgroups header field
>    (Section 3.1.5), with the exception that the keyword "poster"
>    requests that followups should be mailed to the article's reply
>    address rather than posted.  Agents MUST generate the
>    keyword "poster" in lower-case, but MAY choose to recognize
>    case-insensitive forms such as "Poster".

Accepted.

>>    Additionally, any other <parameter> whose <attribute> starts with
>>    "x-" MAY be used where the defined ones appear to be unsuitable,  but
>>    other unlisted <parameter>s SHOULD NOT be used unless defined in
>>    extensions to this standard.
>
> Rewritten:
>
>    Other <attribute>s SHOULD NOT be used unless defined in extensions
>    to this standard.  If non-standards-based <attribute>s are used,  they
>    MUST begin with an "x-".

Accepted.

>>    Although comments and folding of white space are permitted  
>> throughout
>>    the Injection-Info header field, it is RECOMMENDED that folding is
>>    not used within any <parameter> (but only before or after the ";"
>>    separating those <parameter>s), and that comments are only used
>>    following the last <parameter>.
>
>
> [Rewritten:]
>
>    Although comments and folding of white space are permitted  throughout
>    the Injection-Info header field, folding SHOULD NOT be
>    used within any <parameter>.  Folding SHOULD only occur before or  
> after
>    the ";" separating <parameter>s, and comments SHOULD only be used
>    following the last <parameter>.

Accepted.

>>    The header fields listed above are documented for historical  
>> purposes
>>    only.  Articles containing these header fields MUST NOT be  
>> generated.
>>    Persons writing new agents SHOULD ignore any former meanings of  
>> these
>>    header fields.
>
>    The header fields listed above are documented for historical  purposes
>    only.  These header fields MUST NOT be generated and SHOULD be  
> ignored.

Accepted.

Date: Thu, 25 May 2006 17:02:45 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: WG Last Call: draft-ietf-usefor-usefor-08
Sender: [email-masked]

OK folks, it's time.
All tracked issues with this document have been declared resolved, and 
the resolutions entered.
We know of one bug in -08 (the line length phrasing). But it's time to 
make the call.

Please - once you have reviewed draft-ietf-usefor-usefor-08 - reply to 
this Last Call with your answer on the two following points:

1) Is draft-ietf-usefor-usefor-08 ready to go forward?

Possible answers:

A - I believe it is ready to go forward.

B - I believe issues must be fixed; all my issues have been raised by 
others, and once these are resolved, I believe it is ready.

C - I believe issues must be fixed; the following issue has not been 
raised so far: .....................

D - I have another opinion, which is: ...................

2) How should draft-ietf-usefor-usefor-08 be carried forward?

Possible answers:

A - Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call 
and processing (knowing that it will likely be in REF hold at the RFC 
Editor until draft-ietf-usefor-usepro is finished)

B - Put draft-ietf-usefor-usefor into a "WG-internal frozen state", 
where we will promise to only change it if work on USEPRO proves to us 
that we have something wrong in -usefor-.

C - I have another opinion, which is........

This WG Last Call will end two weeks from now, on June 8, 2006, at 17:02 
Central European Time.

                       Harald Alvestrand, for the chairs.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-usefor-usefor-08.txt 
Date: Mon, 22 May 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Usenet Article Standard Update Working Group of the IETF.

	Title		: Netnews Article Format
	Author(s)	: C. Lindsey, et al.
	Filename	: draft-ietf-usefor-usefor-08.txt
	Pages		: 47
	Date		: 2006-5-22
	
This document specifies the syntax of Netnews articles in the context
of the "Internet Message Format" (RFC 2822) and "Multipurpose
Internet Mail Extensions (MIME)" (RFC 2045).  This document
supersedes RFC 1036, updating it to reflect current practice and
incorporating incremental changes specified in other documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-usefor-usefor-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-usefor-usefor-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-usefor-usefor-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-usefor-usefor-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-usefor-usefor-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 22 May 2006 13:42:29 -0400
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: draft-ietf-usefor-usefor-08
Sender: [email-masked]

I just submitted USEFOR draft -08.  This draft includes resolutions to 
the remaining tickets and the non-controversial edits from Dan Kohn.

You can grab the full document from here:

http://www.contrib.andrew.cmu.edu/~murch/draft-ietf-usefor-usefor-08.txt

Or see the diffs from -07 here:

http://tinyurl.com/zlkt2

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

To: [email-masked]
Xref: clerew local.usefor:23283
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Status update (no change)
Date: Fri, 19 May 2006 12:52:50 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> Harald Alvestrand <[email-masked]> writes:

>Just to make sure we're all on the same page....

>I believe we have reached substantial consensus on all issues raised, 
>and we're waiting for version -08 to be published.
>Once -08 is published, we'll close the remaining open tickets, send out 
>a WG Last Call, and see if we are done.

I am not clear what was decided concerning the various fixes proposed by
Dan Kohn. Some of them were improvements, a few were plain wrong, and some
were never resolved (e.g. Email vs email).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Thu, 18 May 2006 09:55:30 +0200
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Status update (no change)
Sender: [email-masked]

Just to make sure we're all on the same page....

I believe we have reached substantial consensus on all issues raised, 
and we're waiting for version -08 to be published.
Once -08 is published, we'll close the remaining open tickets, send out 
a WG Last Call, and see if we are done.

The Last Call will include a poll question on what to do when Last Call 
finishes:

- Pass draft-ietf-usefor-usefor to the IESG for IETF-wide Last Call and 
processing (knowing that it will likely be in REF hold at the RFC Editor 
until draft-ietf-usefor-usepro is finished)

- Put draft-ietf-usefor-usefor into a "WG-internal frozen state", where 
we will promise to only change it if work on USEPRO proves to us that we 
have something wrong in -usefor-.

I hope that either way, we can declare victory on this document and move on.

                     Harald

To: [email-masked]
Xref: clerew local.usefor:23281
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: USEPRO - Path header revisions
Date: Tue, 9 May 2006 21:36:16 GMT
Lines: 348
Sender: [email-masked]

Now that the issues of #1047 are largely resolved (any remaining issues
concern NOTEs about <diag-deprecated> and other non-normative matters), I
thought it would be useful to make all necessary changes to USEPRO to
bring it into line with the new syntax and terminology and to check our
understanding of any relateds protocol changes we have discussed.

This should enable us to identify any problems with what we have written
in USEFOR that might misfit with USEPRO (I have found none so far). But in
any case, it is time we were getting on with USEPRO now that USEFOR is
complete bar matters of style and fixing of typos.

The following are the changes to USEPRO that seem to be necessary. The
great bulk of them are minor fixes to adapt to the revised terminology. It
is only when you come to sections 7.3 and 7.3.1 that there is any major
rewriting.

There are some specific issues mentioned which we need to decide about,
and no doubt people will raise more. But could we please restrict
discussion to matters directly relevant to the Path header, and not to
other matters which might just happen to appear en passage in the texts I
have reproduced.

2.3.  Identification of news servers

[There are two alternative texts which have been proposed:]

   In order to record the passage of articles through the network, news
   servers need to identify themselves by means of a <path-identity>
   (F-3.1.6), which can appear in Path, Injection-Info and Xref header
   fields. Whatever <path-identity> is used in the Path header field
   SHOULD be used also in any Injection-Info header field (and it would
   be normal to use it in any Xref header field also).
[Maybe that last sentence moves elsewhere.]

        NOTE: Such <path-identity>s may also be suitable for sending
        email to news server administrators (see [USEAGE]).

[1st alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that SHOULD be resolvable in
      the DNS (whether via an A, AAAA or MX record or an equivalent
      CNAME), thus guaranteeing a unique identity. Ideally, it will also
      provide a means to contact the administrators by email (according
      to [RFC 2142], the forms "usenet@server" and "news@server" are
      common addresses for a news server administrator).

|  2. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other news
      servers sending articles directly to the given one. This option
      SHOULD NOT be used unless the earlier option is unavailable (e.g.
      because the server in question is not connected to the Internet),
      or unless it is of longstanding usage and cessation would be
      unduly disruptive, or unless the earlier option is provided as
      well.

[2nd alternative]

   <Path-identity>s can take the following forms (in decreasing order of
   preference):

   1. A fully qualified domain name (FQDN) that can be resolved to an
      email server via an MX, A or AAAA record according to the
      procedures of [RFC 2821]; this guarantees that the name is unique,
      and makes it easy to contact the administrators if needed.

   2. A fully qualified domain name (FQDN) that is guaranteed to be
      unique by the administrators of the domain; for instance, the
      uniqueness of "server.example.org" could be guaranteed by the
      administrator of "example.org" even if nothing is stored in the
      DNS for that name.

|  3. Some other (arbitrary) name in the form of a <path-nodot>, and
|     believed to be unique and registered at least with all other
      news-servers sending articles directly to the given one. This
      option SHOULD NOT be used unless the earlier options are
      unavailable, or unless the name is of longstanding usage and
      cessation would be unduly disruptive, or unless one of the earlier
      options is provided as well.

   According to [RFC 2142]], the forms "usenet@server" and "news@server"
   are common addresses for a news server administrator.
[end of alternatives]

|       NOTE: A news server administrator who chooses a <path-nodot>
        which turns out not to be unique will have to bear the
        consequences.

|       NOTE: An IP address is not permitted as a <path-identity>,
|       although it may still appear in a <diag-identity>. Since the
|       syntax permits a colon (":"  which, prior to this standard, was
|       an alternative to the "!"  delimiter) within any <diag-identity>
|       which takes the form of an <IPv6address>, it would be unwise to
|       choose as a <path-nodot> anything composed solely from four or
|       less hexadecimal digits.

3.2.  Transitional Arrangements

|    o The new style of Path header field, using a <diag-match> to allow
|      "!!"  as a delimiter> and introducing <path-diagnostic>s (which
|      can be distinguished from <path-identity>s by their leading ".")
       is already consistent with the previous standards. However, the
       intention is that relaying 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.

7.  Duties of Various Agents

   In this section, the word "trusted", as applied to the source of some
   article, means that an agent processing that article has verified, by
   some means, the identity of that source (which may be another agent
   or a poster).
[I am proposing to s/trusted identity/verified identity/ throughout this
chapter, as it seems to convey the sense better; anyone have any
problems with this?]

7.2.  Duties of an Injecting Agent

   In the normal course of events, an article that has already been
   injected into a Netnews network will never pass through another
   injecting agent.  So, if an injecting agent receives an otherwise
   valid article that has already been injected (as evidenced by the
   presence of an Injection-Date header field, an Injection-Info header
|  field, or more than one occurrence of the <diag-keyword> "POSTED" in
   a Path header field) it MAY choose to reject it, but otherwise SHOULD
   cause it to be relayed, as it stands, by a relaying agent (7.3).

7.2.1.  Proto-articles

        NOTE: An article that is offered for reinjection has, by
        definition, already been injected once, and is not therefore to
        be considered as a proto-article.  Hence a genuine proto-article
|       will not contain any Injection-Date header field nor the <diag-
|       keyword> "POSTED" anywhere in its Path header field, though that
        header field MAY contain <path-identity>s corresponding to
        machines traversed between the posting agent and the injecting
        agent proper.

7.2.2.  Procedure to be followed by Injecting Agents

   10.  It MUST then prepend the <path-identity> of the injecting agent,
|       followed by '!.' and the <diag-keyword> "POSTED", and then a
|       further "!",  to the content of the Path header field; this
        header field SHOULD then be folded if it would otherwise result
        in a header line of excessive length.

7.3.  Duties of a Relaying Agent

   In order to avoid unnecessary relaying, an article SHOULD NOT be
   relayed if the <path-identity> of the receiving agent (or some known
|  alias thereof) appears as a <path-identity> in its Path header field.
|  But note that the <tail-entry> (which follows the last "!") is not a
|  <path-identity>, although not all current implementations observe
|  this distinction.

|  For this to work, each relaying agent needs to insert it own <path-
|  identity> (chosen according to 2.3) into the Path header field. It
|  MAY insert more than one <path-identity> for itself (in which case
|  the leftmost should be the one by which it is known to its immediate
|  neighbours), but where an article passes through several relaying
|  agents at the same site it MAY omit the <path-identity>s for some of
|  them (but NOT the one which finally relays it to an outside site).

|  It MAY (and usually SHOULD) also add a <path-diagnostic> giving
|  additional information concerning the route taken by the article
|  through the network.  A <path-diagnostic> consists of either the
|  special <diag-match> "!" (which effectively replaces the standard
|  delimiter "!" by "!!"), or it is composed from a <diag-keyword> usually
|  followed by a <diag-identity>. The following are the only <diag-
|  keyword>s defined by this standard:
|    o "POSTED" (already introduced in Step 10 of 7.2.2), which is never
|      followed by a <diag-identity>;
|    o "SEEN", whose following <diag-identity> indicates the trusted
|      identity (see 7) of the agent from which the article was received
|      (but makes no claim as to whether it matched the <path-identity)
|      inserted by that agent);
|    o "MISMATCH", whose following <diag-identity> indicates the trusted
|      identity of the agent from which the article was received and
|      asserts that it could not be reconciled with the <path-identity>
|      (supposedly) inserted by that agent.
|  Other <diag-keyword>s beginning with "X" MAY be used by a relaying
|  agent to make some assertion not envisaged here, but other (non-"X")
|  <diag-keyword>s MUST NOT be used unless defined by some extension to
|  this standard.

|       NOTE: The <diag-keyword> "MATCH", which might have indicated the
|       trusted identity of the source agent with an assertion that it
|       agreed with the <path-identity> inserted by that agent, has NOT
|       been provided, since the special <diag-match> conveys exactly
|       that meaning for this commonly occurring case.

|       NOTE: Whilst <diag-keywords>s are case insensitive, it is
|       intended that they should normally be rendered in upper case.

   A relaying agent processes articles as follows:

|     1. It MUST/SHOULD establish the trusted identity of the source of
         the article and compare it with the leftmost <path-identity> of
|        the existing Path header field's content.  Except possibly when
|        relaying to other hosts on the same site, It then MUST or
|        SHOULD, as indicated, prepend to that content (from left to
|        right) the following:
|        o (MUST) its own <path-identity>;
|        o (MUST) a "!" delimiter;
|        o (MUST/SHOULD) if the trusted and existing identities match, a
|          <diag-match> (effectively converting the "!" delimiter into
|          "!!");
|        o (MUST/SHOULD) alternatively, where the identities do not
|          match (or have not been determied to match), a ".", the
|          <diag-keyword> "MISMATCH" (or "SEEN"), another ".", a <diag-
|          identity> indicating the trusted identity, and finally a
|          further "!";
|        o possibly further <path-identity>s etc. as above, identifying
|          itself.
|     This header field SHOULD then be folded if it would otherwise
|     result in a header line of excessive length.
[The "MUST/SHOULD"s above were all "MUST" in the previous drafts.
Discussion is needed to resolve this.]

|       NOTE: Since each agent at one site can be assumed to be aware of
|       the identity of the others (and of itself), it would be most
|       unusual for their <path-identity>s to be separated other than by
|       "!!". Thus the presence of a single "!", unless followed by a
|       "." and some <diag-keyword>, can be taken as signifying an agent
|       that has not yet been upgraded to conform to this standard.

|       NOTE: Whilst the presence of a "MISMATCH" would normally
|       indicate that the existing Path was bogus in some sense, it
|       could also indicate that the ralaying agent was improperly
|       configured to recognise the identities or aliases used by its
|       neighbours. Administators of relaying agents should therefore
|       periodically monitor the <path-diagnostic> being inserted so as
|       to avoid this.

        NOTE: In order to prevent overloading, relaying agents should
        not routinely query an external entity (such as a DNS-server) in
        order to determine a trusted identity (though a local cache of
        the required information might usefully be consulted).

7.3.1.  Path Header Field Example

|     Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example
|        !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A
|        !dubious.site.example!!old.site.example!barbaz!!baz.isp.example
|        !.POSTED!dialup123.baz.isp.example!not-for-mail

        NOTE: That article was injected into the news stream by
|       baz.isp.example, as indicated by the <diag-keyword> "POSTED"
        (complaints may be addressed to [email-masked]). The
        injector has chosen to record that it got it from
        dialup123.baz.isp.example. "not-for-mail" is a dummy <tail-
        entry>, though sometimes a real userid is put there.

        The article was relayed, perhaps by UUCP, to the machine known,
        at least to old.site.example, as "barbaz".

        Barbaz relayed it to old.site.example, which does not yet
|       conform to this standard (hence the single '!' delimiter). So
        one cannot be sure that it really came from barbaz.

|       Old.site.example relayed it to a site claiming to be
|       dubious.site.example, and claiming (by using the '!!'
|       delimiter) to have verified that it came from old.site.example.

|       Dubious.site.example relayed it to "foo-server" which, not being
|       convinced that it truly came from dubious.site.example, and
|       knowing that it in fact arrived from a host with the IPv6address
|       [2001:DB8:0:0:8:800:200C:417A], inserted the <path-diagnostic>
|       "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say
|       that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6
|       address for dubious-site.example, but simply that that
|       connection could not be substantiated by foo-server).

        "foo-server" is a locally significant name within the complex
        site of many machines run by foo.isp.example, so the latter
        should have no problem recognizing foo-server and using a '!!'
|       delimiter. It was not strictly necessary to insert the <path-
|       identity> "foo-server" as well as "foo.isp.example" (but maybe
|       some site elsewhere had some reason to test for it).
[Please could Richard Clayton provide a more plausible reason why "foo-
server" might be a <path-nodot> here?]

|       It then went to bar.isp.example which determined (by reverse
|       DNS) that it had come from news3.foo.isp.example, but had taken
|       no steps to check whether that was a known alias for
|       foo.isp.example (which it probably was). Strictly, it SHOULD
|       have made such a check, and then inserted either a "!!" or a
|       "!MISMATCH..." according to the result.

|       Presumably bar.isp.example then delivered the article to its
        direct clients.

|       It appears that foo.isp.example, foo-server and baz.isp.example
        decided to fold the line, on the grounds that it seemed to be
|       getting a little too long.  Note that folding and whitespace is
|       permitted before (but not after) any "!"  (but not within a
|       "!!"); hence continuation lines will always start with either
|       "!" or "!!".

7.4.  Duties of a Serving Agent

A serving agent processes articles as follows:

|  1. It MUST/SHOULD establish the trusted identity of the source of the
      article and modify the Path header field as for a relaying agent
      (7.3).

7.8.  Duties of a Moderator

   5. Any variant header fields (2.4) MUST be removed, except that a
      Path header field MAY be truncated to only those entries following
|     its "POSTED" <diag-keyword>.  Any Injection-Info header field (F-
      3.2.14) SHOULD be removed (and if not, the injecting agent will do
      so, as required in 7.2.2).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5