Subject: I'm back (finally)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 28 Nov 2005 10:28:43 +0100

Apologies for the long period of silence. I'm now trying to get back around 
to USEFOR - it would be nice to have a final draft of USEFOR before 
Christmas season rolls around.... and there doesn't seem to be that much 
controversy left....

(neither does there seem to be much energy. Not surprising.)

                Harald

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 30 Nov 2005 21:09:37 +0100

> (neither does there seem to be much energy. Not surprising.)

BTW, did you ever get an answer for your question about pseudo-
domains from the IAB, IANA, IESG ?  It's generally interesting:

<http://permalink.gmane.org/gmane.ietf.usenet.format/30159>

                            Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 30 Nov 2005 23:24:25 +0100

> <http://permalink.gmane.org/gmane.ietf.usenet.format/30159>

The feedback I got (not official) was that the 1123 oblique reference was 
the closest we have come to an official statement; I got one comment saying 
that at the time Jon Postel was IANA, he said quite clearly that "there 
will never be a numeric TLD". But I've not managed to find a policy 
document that says so.

I've pushed on the dnsext list for the prohibition to be added to 
draft-eastlake-2606bis, but that hasn't happened so far... meeting some 
resistance, mostly of the "not the IETF's business" type.

                Harald

Date: Wed, 30 Nov 2005 23:24:25 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: I'm back (finally)
Sender: [email-masked]

> <http://permalink.gmane.org/gmane.ietf.usenet.format/30159>

The feedback I got (not official) was that the 1123 oblique reference was 
the closest we have come to an official statement; I got one comment saying 
that at the time Jon Postel was IANA, he said quite clearly that "there 
will never be a numeric TLD". But I've not managed to find a policy 
document that says so.

I've pushed on the dnsext list for the prohibition to be added to 
draft-eastlake-2606bis, but that hasn't happened so far... meeting some 
resistance, mostly of the "not the IETF's business" type.

                Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I'm back (finally)
Date:  Wed, 30 Nov 2005 21:09:37 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

                            Bye, Frank

Date: Wed, 30 Nov 2005 13:46:38 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: #1088 Injection-date (Re: Ticket status, November 28, 2005)
Sender: [email-masked]

Good to see so many things being agreeable...

--On tirsdag, november 29, 2005 16:46:31 +0000 Charles Lindsey 
<[email-masked]> wrote:

>> 1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
>>  "Text proposed" (I have added Russ' proposal of Sept 23 to the tracker)
>
> I disagree, for reasons stated in
> http://www.imc.org/ietf-usefor/mail-archive/msg02500.html.
>
> Russ's "MUST be inserted" is a matter for USEPRO (where it is already
> stated). His "MUST accept" is redundant, insofar as it is always the
> case that agents MUST accept (or rather MUST not reject) the absence of a
> header that is classified as "optional".
>
> There is nothing technically wrong with the present USEFOR 3.2.1. It is
> just slightly bizarre to have a header which "MUST" be inserted, but is
> nevertheless described as optional (though I now accept that situation is
> correct). Therefore I suggested a NOTE, whose latest version is:
>
>     NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
>     article is injected into the network. However, it has not formally
>     been designated as "mandatory" since articles generated by earlier
>     systems which do not include it still need to be accepted.
>
> However, if we do not include such a NOTE, then the present text should be
> left unchanged.

The text that I inserted into the ticket system is (in case people have 
forgotten):

 This header field MUST be inserted whenever an article is
 injected.
 However, software that predates this standard does not use this
 header, and therefore agents MUST accept articles without the
 Injection-Date header field.

I think this text is better than what Charles is proposing.
I don't see anything that is more bizarre than the other uses of MUST in 
the document.

2 for Russ', 1 for Charles' - other opinions?

                     Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1102
Date:  Wed, 30 Nov 2005 08:38:41 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Charles Lindsey wrote:

> I have already offered to write the detailed changes that
> would be needed.  Looks Like I should go ahead and do that
> anyway, so that people can see exactly what the consequences
> would be.

I'd guess that this will be a rather boring hour with an editor
resulting in a better readable version of the text (plus a few
corresponding changes in USEPRO).

How about waiting for -06, worst case there are still some
issues fixed in -07, and then offer a -08 for #1102 and WGLC ?

About two weeks to read -06 and prepare -07, and publish -08
immediately after -07.  If the only WGLC problem is #1102 for
some obscure reason simply republish -07 as -09 for the IETF
"last call".  With Harald's plan to be ready for WGLC before
2006 we'd need -06 (without #1102) at 2005-12-10.  Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22730
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Ticket status, November 28, 2005
Date: Tue, 29 Nov 2005 16:46:31 GMT
Lines: 93
Sender: [email-masked]

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

>It's been a long time since the last one.
>Here's the current list - 17 USEFOR tickets open.

You omitted to mention #1051, #1081, #1083 and #1093, but it appears these
are all for USEPRO or USEAGE, which is fair enough.

I agree with all the ones described as "Text accepted". That leaves:

>1047 USEFOR 3.1.6: Path field delimiters and components
>"Text proposed"

Currently under discussion.

>1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field in 
>email
> "No consensus"

Curently under dicussion, but can go in USEAGE if we cannot agree otherwise.

>1079 USEFOR 2.1: List all header fields which don't allow comments
> "Text proposed"

That is fine.

>1080 USEFOR 3.2.14: MIME parameters for Injection-Info and Archive
> header field need more text/updated syntax
>  "Text proposed"

That is fine.

>1082 USEFOR 3.2.9: Need more text about Approved header field semantics?
>  "Text proposed"

That is fine.

>1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
>  "Proposed No Change"

That is fine.

>1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
>  "Text proposed" (I have added Russ' proposal of Sept 23 to the tracker)

I disagree, for reasons stated in
http://www.imc.org/ietf-usefor/mail-archive/msg02500.html.

Russ's "MUST be inserted" is a matter for USEPRO (where it is already
stated). His "MUST accept" is redundant, insofar as it is always the
case that agents MUST accept (or rather MUST not reject) the absence of a
header that is classified as "optional".

There is nothing technically wrong with the present USEFOR 3.2.1. It is
just slightly bizarre to have a header which "MUST" be inserted, but is
nevertheless described as optional (though I now accept that situation is
correct). Therefore I suggested a NOTE, whose latest version is:

    NOTE: [USEPRO] REQUIRES this header field to be inserted whenever an
    article is injected into the network. However, it has not formally
    been designated as "mandatory" since articles generated by earlier
    systems which do not include it still need to be accepted.

However, if we do not include such a NOTE, then the present text should be
left unchanged.

>1101 USEFOR 3: Empty article bodies - yes/no?
>  "No change needed"

That is fine.

>1102 USEFOR 1: Definition of "agents" or of "server/UA"?
>  "Proposed No Change"

Currently under discussion.

>1132 UEFOR 3.1.6: Outlaw IP address in path-identity?
>  "Text accepted" (although the actual text is in #1047)

The principle is agreed, though the precise text is still under discussion
(#1047)

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22729
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1078 (was: Ticket status, November 28, 2005)
Date: Tue, 29 Nov 2005 15:23:21 GMT
Lines: 49
Sender: [email-masked]

>> 1078 USEFOR 3.1.5: need to describe meaning of Newsgroups
>> header field in email  "No consensus"

There are two current, and conflicting, practices.

1. A followup which is also emailed includes a Newsgroups header.

2. An email reply, not posted to a newsgroup, includes a Newsgroups header
(I believe only a very few user agents do this - can someone name them?).

I think it is agreed that #1 is a reasonable convention and #2 is not, but
until some standard (or BCP) settles the matter, recipients of the email
have no way to interpret what is going on. As soon as some documents makes
it clear, you can use that document to beat about the head anyone who uses
the "wrong" convention.

>_Iff_ we do this it should IMHO be in USEAGE, maybe as a
>chapter with considerations for combined mail and news agents.

I agree that if it cannot be covered in USEFOR (through lack of
consensus), then it could be said in USEAGE. The main argument against
saying it in USEFOR was some doubt as to whether we were allowed to define
such a meaning for email (even though Newsgrpoups is "our" header). I did
ask Harald to enquire of IESG whether this was indeed allowable or not.

>IIRC most of "us" (TINU) didn't want this, but it's not yet
>clear if we should do the opposite, i.e. explain what "To:"
>or "Cc:" probably mean if they show up in news.

I would have no problem mentioning that possibility in USEAGE. Our earlier
"article" drafts supported convention #1 for the Newsgroups header, but
mentioned "To:" and "Cc:" within news articles as an optional possibility
(though actually it is quite a good idea, so certainly mentionable in
USEAGE).

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22727
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 - Path Syntax
Date: Tue, 29 Nov 2005 14:25:08 GMT
Lines: 82
Sender: [email-masked]

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

>I think you have correctly identified the contentious items. I've added 
>this text as a comment to the tracker.

>--On fredag, november 25, 2005 18:21:29 +0000 Charles Lindsey 
><[email-masked]> wrote:

>>    (i) Do we want it to be obvious which entries are "diagnostic" so that
>> humans can spot them  .....

>My work on names used in current messages revealed fairly heavy use of path 
>components that weren't hostnames.... the choices before us are (in my 
>opinion):

Yes, it happens, but I son't think we should do anything to encourage the
continuation of the practice. I recently proposed, as a compromise, that
the text in USEPRO should say that the domain name in a path-identity
SHOULD resolve to something in the DNS (which is the same thing as saying
that domain-names that don't resolve SHOULD NOT be used). That would not
stop it from happening, but would hopefully lead to a reduction in the
practice. Nothing breaks if it happens, but it does make life harder for
humans who are trying to diagnose some problem that has arisen. Would you
accept the wording I proposed?

>- Declare that "anything that isn't a [known?] hostname can be treated like 
>a diagnostic" (my proposal the last time around). This effectively blesses 
>all existing practice - maximum interoperability, but makes life hard for 
>parsers that are looking for diagnostics.
>- Declare a specific syntax for diagnostic, and say "anything else is a 
>hostname" - also blesses existing practice, but relaxes the rules for 
>hostnames quite a bit
>- Declare a specific syntax for diagnostic, keep a strict formulation for 
>hostnames, and declare that anything else is a protocol error (that's how I 
>interpret your proposals).

Not quite. The existing practice will surely continue for some time, but
if we provide a notation to make it clear which entries are diagnostic,
then we should prefer that it should be used in future. I am sure I
could add some wording to my proposal to make it clear that such existing
practices should continue to be accepted. Nobody currently rejects articles
with unparseable Path headers (unless the errors are exceedingly gross)
because it is just too much work in a critical part of the code.

>I think a more basic issue is to decide between 2-element diagnostics 
>(!!keyword! or !keyword!diag!) and 1-element diagnostics 
>(!diag..keyword!). That folds in your (iii)....

I prefer the 1-element form because it reduces the small possibility that
some agent would try to use the diagnostic as a path-identity (though that
agent would have to be pretty stupidly configured as well). It also
removes any possibility of confusing a keyword with a <bareword>.
However, as I said, the 2-element form is in the present draft, so it
would remain if we cannot agree to change it (and "POSTED" would still
have to come in the 2-element form because the thing to the left of it is
a genuine path-identity - not a diagnostic).

>> But clearly, we MUST answer question (i), and if that point is agreed,
>> then we MUST answer question (ii) as well. Question (iii) is less
>> important.

>Yes, we have to answer question (i) (in my opinion).

Indeed. My view is that diagnostics should be readily identifiable as
such.  Currently that is not the case. The fact that IP addresses are
currently 99% certain to be diagnostic is not written down anywhere, nor
is it widely understood (we only know because we have researched it). It
seems that the new notations proposed (e.g. a keyword SEEN) can improve
the situation if they become adopted over time, and can do so without
preventing any existing software from continuing to work.

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22728
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1102 (was: Ticket status, November 28, 2005)
Date: Tue, 29 Nov 2005 14:33:38 GMT
Lines: 35
Sender: [email-masked]

>> 1102 USEFOR 1: Definition of "agents" or of "server/UA"?
>>   "Proposed No Change"

>Was that really the last state ?  I vaguely recall that some
>prefer to talk about "news servers" and "UAs" in USEFOR.

Actually, I would make it "serving agents" and "user agents" in USEFOR
(for symetry), and change the existing "serving agent" in USEPRO to
"storage agents" (which better describes what they do).	

>IIRC the details about "relaying agents" affect only USEPRO,
>and the whole concept of a "followup agent" is unnecessary.

I agree with Frank here. Nobody actually objected to simplifying the
wording in USEFOR, and it would simplify my task of finally removing all
duplications on information between USEFOR and USEPRO.

I have already offered to write the detailed changes that would be needed.
Looks Like I should go ahead and do that anyway, so that people can see
exactly what the consequences would be.

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22726
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1080 - description of Injection-Info
Date: Tue, 29 Nov 2005 11:13:04 GMT
Lines: 21
Sender: [email-masked]

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

>I have entered this into the tracker as "proposed text", and set the status 
>to "Text proposed" - I believe that the general format is a reasonable 
>approach, while I may quibble over formulations.

Fair enough. I presume that is without that "gibbous" note at the end.

If anyone has quibbles over the formulations, then let us have them and
fix them.

-- 
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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1078 (was: Ticket status, November 28, 2005)
Date:  Mon, 28 Nov 2005 11:36:33 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> 1078 USEFOR 3.1.5: need to describe meaning of Newsgroups
> header field in email  "No consensus"

IIRC most of "us" (TINU) didn't want this, but it's not yet
clear if we should do the opposite, i.e. explain what "To:"
or "Cc:" probably mean if they show up in news.

_Iff_ we do this it should IMHO be in USEAGE, maybe as a
chapter with considerations for combined mail and news agents.

If I got this right #1078 wrt USEFOR could be "no change" (?)

                          Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  #1102 (was: Ticket status, November 28, 2005)
Date:  Mon, 28 Nov 2005 11:24:51 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

Harald Tveit Alvestrand wrote:

> 1102 USEFOR 1: Definition of "agents" or of "server/UA"?
>   "Proposed No Change"

Was that really the last state ?  I vaguely recall that some
prefer to talk about "news servers" and "UAs" in USEFOR.

IIRC the details about "relaying agents" affect only USEPRO,
and the whole concept of a "followup agent" is unnecessary.

Pure "posting agents" are rare and not really interesting:
If it's one of those "multipart FAQ posting agents", then it
should know how References work like any "followup agent".

In your "I'm back" article you said:

> it would be nice to have a final draft of USEFOR before 
> Christmas season rolls around

First Advent was yesterday :)  I'd settle for a "new" draft
not necessarily "final":  #1102 would be only a bulk editorial
effort, nothing substantial.
                               Bye, Frank

Date: Mon, 28 Nov 2005 10:28:43 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: I'm back (finally)
Sender: [email-masked]

                Harald

Date: Mon, 28 Nov 2005 10:26:28 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: #1102 Server/UA vs agents: "Proposed no change"
Sender: [email-masked]

After reviewing the discussion of #1102, I propose that we make no change.
The cost does not seem to be worth the benefit.

Date: Mon, 28 Nov 2005 10:25:40 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Ticket status, November 28, 2005
Sender: [email-masked]

It's been a long time since the last one.
Here's the current list - 17 USEFOR tickets open.

1003 USEFOR 3.1.3 - Cleanup ABNF for msg-id
"Text accepted"

1028 USEFOR 3.1.2 Date: What zones should be on the MUST accept list?
"Text accepted"

1029 USEFOR 3.2.2 References: Should comments be a MUST NOT?
"No change"

1032 USEFOR general: Document changes from RFC 1036
"Text needed" - waiting for Ken to propose text

1046 USEFOR 5. MIME boundary security considerations
"Text accepted"

1047 USEFOR 3.1.6: Path field delimiters and components
"Text proposed"

1052 USEFOR general: Document changes from RFC 2822
"Text accepted"

1053 USEFOR 2.1 Relationship to RFC 2822
"Text accepted"

1078 USEFOR 3.1.5: need to describe meaning of Newsgroups header field in 
email
 "No consensus"

1079 USEFOR 2.1: List all header fields which don't allow comments
 "Text proposed"

1080 USEFOR 3.2.14: MIME parameters for Injection-Info and Archive
 header field need more text/updated syntax
  "Text proposed"

1082 USEFOR 3.2.9: Need more text about Approved header field semantics?
  "Text proposed"

1084 USEFOR 2.1, 3: Names for ABNF productions redefining 822 constructs
  "Proposed No Change"

1088 USEFOR 3.2.1: Should Injection-Date header be mandatory or optional?
  "Text proposed" (I have added Russ' proposal of Sept 23 to the tracker)

1101 USEFOR 3: Empty article bodies - yes/no?
  "No change needed"

1102 USEFOR 1: Definition of "agents" or of "server/UA"?
  "Proposed No Change"

1132 UEFOR 3.1.6: Outlaw IP address in path-identity?
  "Text accepted" (although the actual text is in #1047)

When discussing the specific issues, please include the number in the 
subject header, and STAY ON TOPIC.

Thanks!

                       Harald

Date: Mon, 28 Nov 2005 09:46:17 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1047 - Path Syntax
Sender: [email-masked]

I think you have correctly identified the contentious items. I've added 
this text as a comment to the tracker.

--On fredag, november 25, 2005 18:21:29 +0000 Charles Lindsey 
<[email-masked]> wrote:

> If those changes are agreed, then they need text to describe them. Before
> writing that text, there are some minor details to sort out:
>
>    (i) Do we want it to be obvious which entries are "diagnostic" so that
> humans can spot them (they are also to be ignored when deciding whether to
> send an article to some peer). There was some desire expressed for this
> (but note that diagnostics are not necessarily IP addresses, because some
> articles may arrive other than by NNTP).

My work on names used in current messages revealed fairly heavy use of path 
components that weren't hostnames.... the choices before us are (in my 
opinion):

- Declare that "anything that isn't a [known?] hostname can be treated like 
a diagnostic" (my proposal the last time around). This effectively blesses 
all existing practice - maximum interoperability, but makes life hard for 
parsers that are looking for diagnostics.
- Declare a specific syntax for diagnostic, and say "anything else is a 
hostname" - also blesses existing practice, but relaxes the rules for 
hostnames quite a bit
- Declare a specific syntax for diagnostic, keep a strict formulation for 
hostnames, and declare that anything else is a protocol error (that's how I 
interpret your proposals).

I think it's relatively simple to declare the field of "diagnostics" wide 
open and later say "here is a specific set of diagnostics, with a 
standardized meaning" - that could even be done in USEPRO, without anything 
in USEFOR. It's a little messy (problem should be obvious), but has the 
procedural advantage of letting us finish USEFOR without answering (ii) or 
(iii).

>    (ii) If so, then what notation to use? Keywords seem the obvious
> answer, since the present draft (and some existing usage) already uses
> "MISMATCH".  Present usage seems to use IP addresses (at least)
> diagnostically without any indication at all (contrary to (i)), so I
> suggested using the keyword "SEEN". I also suggested "MATCH" to complete
> the set, but that is not essential given that we also have the "!!"
> notation. There was also a suggestion to leave the set of keywords
> open-ended.

I think a more basic issue is to decide between 2-element diagnostics 
(!diag!keyword! or !keyword!diag!) and 1-element diagnostics 
(!diag..keyword!). That folds in your (iii)....
>
>    (iii) We also need to decide the format of keywords. But at least, if
> we cannot achieve consensus on that we can just fall back to the present
> draft which uses, for example, "...!123.123.123.123!MISMATCH!...". The
> alternative I have suggested is "...!123.123.123.123..MISMATCH!...", which
> is closer to some existing usage.
>
> But clearly, we MUST answer question (i), and if that point is agreed,
> then we MUST answer question (ii) as well. Question (iii) is less
> important.

Yes, we have to answer question (i) (in my opinion).

Date: Mon, 28 Nov 2005 09:27:25 +0100
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1080 - description of Injection-Info
Sender: [email-masked]

I have entered this into the tracker as "proposed text", and set the status 
to "Text proposed" - I believe that the general format is a reasonable 
approach, while I may quibble over formulations.

                Harald

--On fredag, november 11, 2005 20:34:36 +0000 Charles Lindsey 
<[email-masked]> wrote:

>
> AIUI, the present state of play is as follows:
>
> 1. Injection-Info currently makes use of MIME-style parameters.
>
> 2. It was always intended that these paramaters should accord in all
> applicable respects with those defined in RFC 2045 plus RFC 2231.
>
> 3. It is not in dispute that the description in the current USEFOR does
> not accord with RFC 2045, since it gives separate ABNF for each
> <parameter>, which permits or does not permit CFWS in the proper places,
> and which does not provide for encapsulation in <quoted-string>s in the
> proper places. Also, it should be noted that RFC 2046 never gives ABNF for
> specific <parameter>s, presumably for that same reason.
>
> 4. There is some disquiet about the unnecessary complications introduced
> by the more gibbous features of RFC 2231. Nevertheless, everybody (except
> possibly Bruce) has, at one time or another, expressed a willingness to
> live with MIME-style parameters if nothing else is seen to be forthcoming.
>
> 5. The possibility of an entirely different syntax has been mooted from
> time to time but, at the last poll that was conducted, there was clearly
> no consensus to embark on such a step, and I doubt Harald would wish us to
> embark on reinventing any such wheels at the present time.
>
> 6. Absent such a major change of direction, it only remains to fix the
> problems mention in #3 above. I proposed a text some while back, but Russ
> seemed to suggest there might be some other fix possible, though we have
> seen no details of any other fix.
>
> 7. I therefore repeat my proposed text below (with a few tunings in the
> light of discussion). AFAICS, it fixes the problem. Is there now any
> reason not to adopt this text, and to move on?
>
> 8. In recognition about concerns with the gibbousness of RFC 2231, there
> is a NOTE at the end indicating why it is hardly necessary to use it. If
> people want such a text, then let it stay - I am neutral on it.  It there
> is any doubt about whether it should be there, then it should probably
> come out.
>
>
>    injection-info  =  "Injection-Info:" SP [CFWS] path-identity
>                       [CFWS] *( ";" parameter ) CRLF
>
>      NOTE: The syntax of <parameter> ([RFC2045] as amended by
>      [RFC2231]), taken in conjunction with the folding rules of [RFC
>      822], effectively allows [CFWS] to occur both before and after the
>      <parameter>, and also on either side of its "=".
>
>    The following table gives the <attribute> and the format of the
>    <value> for each <parameter> defined for use with this header field.
>    At most one occurrence of each such <parameter> is allowed.
>
>    <attribute>                           format of <value>
>    -------------------------------------------------------
>
>    "posting-host"                        a <host-value>
>    "posting-account"                     any <value>
>    "sender"                              a <sender-value>
>    "logging-data"                        any <value>
>    "mail-complaints-to"                  an <address-list>
>
>    where
>
>    host-value      =  dot-atom-text /
>                       [ dot-atom-text ":" ] ( IPv4address / IPv6address )
>                                        ;  see [RFC 3986]
>    sender-value    =  mailbox / "verified"
>
>      NOTE: Since any such <host-value>, <sender-value> or <address-list>
>      has also to be a syntactically correct <value>, it will usually be
>      necessary to encapsulate is as a <quoted-string>, for example:
>
>      sender = "\"Joe Q. Public\" <[email-masked]>"
>
>    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.
>
> [The inclusion or not of the following NOTE is to be discussed by the WG.]
>
>      NOTE: Should Non-ASCII characters be required in any <value>, the
>      mechanisms described in Section 4 of [RFC 2231] are available.
>      However, it is unlikely that the more gibbous mechanisms of Section
>      3 will be needed, given the possibility of folding within
>      <quoted-string>s and the lack of any limit on the length of a
>      header line short of the maximum 998 characters.
>
>
> --
> 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
>
>

To: [email-masked]
Xref: clerew local.usefor:22718
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1047 - Path Syntax
Date: Fri, 25 Nov 2005 18:21:29 GMT
Lines: 87
Sender: [email-masked]

In <215B75666F1D0DE711CBA5C5@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>I'm at the IETF this week, and at IEEE next week. So I can't follow up =
>much.

OK, but you seem to have done a good job on the IMA stuff.

>But consider this for a moment:

>Given the total inability this group has had on getting consensus on even=20
>minor tightenings or changes to the current models - what's the *minimum*=20
>amount of specification that can get this piece finished?

Well I went through the list of issues on the website, and there seemed
three that still needed significant work:
    #1047
    #1080
    #1102
So I wrote proposals on the first two to try and get some movement
(haven't gotten around to the 3rd yet). The rest of the issues seemed like
they were mostly agreed (though the web site didn't seem quite up to date
on a few minor niggles).

Now, as to #1047, what are we to do?

We could say "leave it as it stands in the current draft, since we have no
agreement on anything further" (indeed, that would suit me fine).

However, the WG had agreed on some changes:
   a) That some entries were "diagnostic" (I prefer to call them
"source-entries" but that is a minor detail), and diagnostic entries were
to be the only ones where IP addresses were allowed - normal path-entries
were to be restricted to domains or barewords.
   b) The only place where a ":" was to be permitted was within IP
addresses (and specifically within IPv6 addresses). That would reduce the
possible occurrences of the "dead:beef" problem to an acceptable level.

If those changes are agreed, then they need text to describe them. Before
writing that text, there are some minor details to sort out:

   (i) Do we want it to be obvious which entries are "diagnostic" so that
humans can spot them (they are also to be ignored when deciding whether to
send an article to some peer). There was some desire expressed for this
(but note that diagnostics are not necessarily IP addresses, because some
articles may arrive other than by NNTP).

   (ii) If so, then what notation to use? Keywords seem the obvious
answer, since the present draft (and some existing usage) already uses
"MISMATCH".  Present usage seems to use IP addresses (at least)
diagnostically without any indication at all (contrary to (i)), so I
suggested using the keyword "SEEN". I also suggested "MATCH" to complete
the set, but that is not essential given that we also have the "!!"
notation. There was also a suggestion to leave the set of keywords
open-ended.

   (iii) We also need to decide the format of keywords. But at least, if
we cannot achieve consensus on that we can just fall back to the present
draft which uses, for example, "...!123.123.123.123!MISMATCH!...". The
alternative I have suggested is "...!123.123.123.123..MISMATCH!...", which
is closer to some existing usage.

But clearly, we MUST answer question (i), and if that point is agreed,
then we MUST answer question (ii) as well. Question (iii) is less
important.

The text I proposed is easily tweaked to fit any answers to those
questions, but I suggest tweaking details is less important than agreeing
the answers in principle.

As to #1080, the present draft is plainly buggy. The text I suggested is
the only show currently in town, as Frank has said, but probably omitting
the "gibbous" paragraph. The only alternative (minor tweaks excepted) is a
completely new notation for Injection-Info, and I don't think the WG
really has the stomache for that.

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22716
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1080 - description of Injection-Info
Date: Tue, 15 Nov 2005 11:15:29 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> Are you happy with the rest of it?

>As long as Bruce proposes no better solution - in a form ready
>for his own review (and relatively minor obstacles like Gen-Art
>or the IESG) - it's the only Injection-Info game in town:

><http://mid.gmane.org/[email-masked]>

>I haven't checked that all [CFWS] are where they should be,
>and I'm lost with your revised revisions of something that
>I've never seen, because it's not draft-ietf-usefor-usefor-05.

I hope it is clear which paragraphs of USEFOR are to be replaced. For the
removal of doubt, the existing 1st para from USEFOR 3.2.14 remains, the
ABNF syntax is replace by my text (probably without the "gibbous" bit),
and all existing USEFOR paragraphs following the present ABNF remain.

-- 
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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1080 - description of Injection-Info
Date:  Mon, 14 Nov 2005 14:59:30 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Charles Lindsey wrote:

> Are you happy with the rest of it?

As long as Bruce proposes no better solution - in a form ready
for his own review (and relatively minor obstacles like Gen-Art
or the IESG) - it's the only Injection-Info game in town:

<http://mid.gmane.org/[email-masked]>

I haven't checked that all [CFWS] are where they should be,
and I'm lost with your revised revisions of something that
I've never seen, because it's not draft-ietf-usefor-usefor-05.

                         Bye, Frank

To: [email-masked]
Xref: clerew local.usefor:22714
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: #1080 - description of Injection-Info
Date: Mon, 14 Nov 2005 11:54:57 GMT
Lines: 27
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Charles Lindsey wrote:

>> However, it is unlikely that the more gibbous mechanisms of
>> Section 3 will be needed, given the possibility of folding
>> within <quoted-string>s and the lack of any limit on the
>> length of a header line short of the maximum 998 characters.

>Get rid of that, it doesn't help.  The proposed "security
>considerations" already take care of some gibbous 2822 / 2231
>"features".

Yes, I have no problem with getting rid of that if people do not want it.

Are you happy with the rest of it?

-- 
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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: #1080 - description of Injection-Info
Date:  Sat, 12 Nov 2005 21:08:29 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 16
Sender: [email-masked]

Charles Lindsey wrote:

> However, it is unlikely that the more gibbous mechanisms of
> Section 3 will be needed, given the possibility of folding
> within <quoted-string>s and the lack of any limit on the
> length of a header line short of the maximum 998 characters.

Get rid of that, it doesn't help.  The proposed "security
considerations" already take care of some gibbous 2822 / 2231
"features".

If implementors still don't get the message (= "PITA"), then
your "however...unlikely" note declaring that a problem is no
real problem makes it worse.
                               Bye, Frank

Date: Sat, 12 Nov 2005 10:17:04 +0100
From: [email-masked] (Ralph Babel)
To: [email-masked]
Subject: Re: #1080 - description of Injection-Info
Sender: [email-masked]

Charles Lindsey wrote:

> Nevertheless, everybody (except possibly Bruce) has,
> at one time or another, expressed a willingness to
> live with MIME-style parameters if nothing else is
> seen to be forthcoming.

No, Mr. "Editor".

http://imc.org/ietf-usefor/mail-archive/msg02554.html

To: [email-masked]
Xref: clerew local.usefor:22710
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1080 - description of Injection-Info
Date: Fri, 11 Nov 2005 20:34:36 GMT
Lines: 99
Sender: [email-masked]

AIUI, the present state of play is as follows:

1. Injection-Info currently makes use of MIME-style parameters.

2. It was always intended that these paramaters should accord in all
applicable respects with those defined in RFC 2045 plus RFC 2231.

3. It is not in dispute that the description in the current USEFOR does
not accord with RFC 2045, since it gives separate ABNF for each
<parameter>, which permits or does not permit CFWS in the proper places,
and which does not provide for encapsulation in <quoted-string>s in the
proper places. Also, it should be noted that RFC 2046 never gives ABNF for
specific <parameter>s, presumably for that same reason.

4. There is some disquiet about the unnecessary complications introduced
by the more gibbous features of RFC 2231. Nevertheless, everybody (except
possibly Bruce) has, at one time or another, expressed a willingness to
live with MIME-style parameters if nothing else is seen to be forthcoming.

5. The possibility of an entirely different syntax has been mooted from
time to time but, at the last poll that was conducted, there was clearly
no consensus to embark on such a step, and I doubt Harald would wish us to
embark on reinventing any such wheels at the present time.

6. Absent such a major change of direction, it only remains to fix the
problems mention in #3 above. I proposed a text some while back, but Russ
seemed to suggest there might be some other fix possible, though we have
seen no details of any other fix.

7. I therefore repeat my proposed text below (with a few tunings in the
light of discussion). AFAICS, it fixes the problem. Is there now any
reason not to adopt this text, and to move on?

8. In recognition about concerns with the gibbousness of RFC 2231, there
is a NOTE at the end indicating why it is hardly necessary to use it. If
people want such a text, then let it stay - I am neutral on it.  It there
is any doubt about whether it should be there, then it should probably
come out.

   injection-info  =  "Injection-Info:" SP [CFWS] path-identity
                      [CFWS] *( ";" parameter ) CRLF

     NOTE: The syntax of <parameter> ([RFC2045] as amended by
     [RFC2231]), taken in conjunction with the folding rules of [RFC
     822], effectively allows [CFWS] to occur both before and after the
     <parameter>, and also on either side of its "=".

   The following table gives the <attribute> and the format of the
   <value> for each <parameter> defined for use with this header field.
   At most one occurrence of each such <parameter> is allowed.

   <attribute>                           format of <value>
   -------------------------------------------------------

   "posting-host"                        a <host-value>
   "posting-account"                     any <value>
   "sender"                              a <sender-value>
   "logging-data"                        any <value>
   "mail-complaints-to"                  an <address-list>

   where

   host-value      =  dot-atom-text /
                      [ dot-atom-text ":" ] ( IPv4address / IPv6address )
                                       ;  see [RFC 3986]
   sender-value    =  mailbox / "verified"

     NOTE: Since any such <host-value>, <sender-value> or <address-list>
     has also to be a syntactically correct <value>, it will usually be
     necessary to encapsulate is as a <quoted-string>, for example:

     sender = "\"Joe Q. Public\" <[email-masked]>"

   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.

[The inclusion or not of the following NOTE is to be discussed by the WG.]

     NOTE: Should Non-ASCII characters be required in any <value>, the
     mechanisms described in Section 4 of [RFC 2231] are available.
     However, it is unlikely that the more gibbous mechanisms of Section
     3 will be needed, given the possibility of folding within
     <quoted-string>s and the lack of any limit on the length of a
     header line short of the maximum 998 characters.

-- 
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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  OT: IMA (IEE BoF) jabber log
Date:  Fri, 11 Nov 2005 06:10:53 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 41
Cc: [email-masked]
Sender: [email-masked]

FYI, the IEE BoF jabber log is available at:
http://www.xmpp.org/ietf-logs/[email-masked]/2005-11-10.html

Mailing list now also available at GMaNe (NNTP, RSS, search):
http://dir.gmane.org/gmane.ietf.ima

The project URL (until IEE is a WG) is apparently:
http://www.alvestrand.no/ietf/iee-bof/

Interesting snippets from the jabber log (thanks to Lisa):

[15:57:15] <lisa> Harald: There's a not-widely implemented
                          standard for tagging language of
                          email headers (RFC2231)

{16:04:42] <cyrus_daboo>  MUAs are important. There are still
                          many MUAs in use today that do not
                          support utf8 even in the message
                          body. So I agree with Chris.

[16:24:39] <cyrus_daboo>  PS If its not already on the list of
                          things to 'fix': the mailto URI
                          scheme will need some work too.

[16:29:36] <lisa> Keith:  There are multiple ways to fail, and
                          fragmenting the email system is one.
                          People to have to manually manage
                          their technology based on who they're
                          talking to is another. They're both
                          bad, both need to be avoided.

[16:34:24] <lisa> Keith:  If you don't have enough MUA
                          implementors in the room it's hard to
                          know if what you're doing is realistic.
[16:34:38] <lisa> Harald: Mailing list is [email-masked].
[16:35:25] <lisa> Harald: The group will continue work on the
                          charter on the mailing list, find a
                          chair, all the usual stuff, and will
                          then continue the conversation with
                          our area director.

Date: Thu, 10 Nov 2005 17:14:04 -0800
From: Harald Tveit Alvestrand <[email-masked]>
To: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: #1047 - Path Syntax
Sender: [email-masked]

--==========AC8E4702E99267C92A05==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I'm at the IETF this week, and at IEEE next week. So I can't follow up =
much.

But consider this for a moment:

Given the total inability this group has had on getting consensus on even=20
minor tightenings or changes to the current models - what's the *minimum*=20
amount of specification that can get this piece finished?

--==========AC8E4702E99267C92A05==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

--==========AC8E4702E99267C92A05==========--

To: [email-masked]
Xref: clerew local.usefor:22707
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1047 - Path Syntax
Date: Thu, 10 Nov 2005 20:05:23 GMT
Lines: 186
Sender: [email-masked]

Things have gone quiet. In an effort to get things moving, I have been
through the outstanding issues and extracted those which appear to be
holding us up. Here is where I think we are at with the Path Syntax:

There are two orthogonal choices for the WG to make in the following
proposal:

1. Syntactic style for the <source-keyword>s "MISMATCH" etc:

version 1:
   Path: downstream.example.com!123.123.123.123!MISMATCH
   !injector.example.com!POSTED!not-for-mail
version 2:
   Path: downstream.example.com!123.123.123.123..MISMATCH
   !injector.example.com!POSTED!not-for-mail

Observe that POSTED has '!'s on either side in both versions, because
peering sites still need to be able to recognize that articles should
not be sent back to injector.example.com.

2. The list of <source-keyword>s.

The proposed set is "SEEN", "MATCH", "MISMATCH". The WG may want to
reduce this (MATCH is redundant because of "!!") or extend it (Harald
even suggested letting sites invent additional ones).

I would suggest that we resolve these two main issues first, before
proceeding to any minor tuning.

3.1.6  Path
 
   The Path header field indicates the route taken by an article since
   its injection into the Netnews system.  Each agent that processes an
|  article is required to prepend a <path-entry> to this header field
   body. .......

[1st version of syntax, following the usage of MISMATCH in the present
USEFOR.]

   path = "Path" ":" SP [FWS] *( path-entry [ source-entry / "!" ] )
             tail-entry [FWS] CRLF

   path-entry = 1*( path-identity [FWS] "!" ) [ "POSTED" [FWS] "!" ]

   source-entry = source-identity [FWS] "!" source-keyword  [FWS] "!"

   source-keyword = "SEEN" / "MATCH" / "MISMATCH"

[2nd version of syntax, with MISMATCH etc incorporated into the
identity.]

   path = "Path" ":" SP [FWS] *( path-entry [ source-entry / "!" ] )
             tail-entry [FWS] CRLF

   path-entry = 1*( path-identity [FWS] "!" ) [ "POSTED" [FWS] "!" ]

   source-entry = source-identity source-keyword [FWS] "!"

   source-keyword = ( "..SEEN" / "..MATCH" / "..MISMATCH" )

[syntax common to both versions.]

   path-identity = fqdn / bareword

   fqdn = 1*( label "." ) toplabel

   label = alphanum / alphanum *( alphanum / "-" ) alphanum

   toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]    ; at least one ALPHA

   alphanum = ALPHA / DIGIT

   bareword = ALPHA / ALPHA *( alphanum / [ "-" / "_" ] ) alphanum )

   tail-entry = fqdn / bareword

[how about tail-entry = 1*( alphanum / "-" / "_" / "." ) ?]

   source-identity = fqdn / IP-address / bareword

   IP-address = IPv4address / IPv6address ;  see [RFC 3986]

   Each <path-entry> (but not the <tail-entry>) indicates, from right to
   left, the successive sites through which the article has passed.  The
   keyword "POSTED" indicates that the site to its left injected the
   article.

   A <source-entry> indicates the true source from which the site to its
   left acquired the article, with the <source-keyword> showing its
   relationship with the <path-entry> inserted by the site to its right
   thus:
       MATCH    they are asserted to be the same, modulo known aliases,
       MISMATCH they are asserted not to be the same,
       SEEN     no asertion is made.
   The presence of two "!"s in succession (the second being an
   alternative to a <source-entry>) is also an assertion that the true
   source matched the <path-entry> to the right (hence the use of the
   <source-keyword> "MATCH" is redundant, and it was only included for
   completeness).

   The full procedure for constructing a <path-entry> as well as the
   preferred format to be used in a <path-identity> are discussed in
   [USEPRO].

      NOTE: An <IPv6address> is the only place where a ":" can occur
      within a <path-entry>. Since some current news-servers may treat
      ":" as a delimiter (in addition to the customary "!"), it is
      inadvisable for any <bareword> to be composed only from
      hexadecimal digits.

      NOTE: Historically, the <tail-entry> .........

      NOTE: Although case-insensitive, it is intended that "SEEN",
      "POSTED" and "MISMATCH" should be in upper case, to distinguish
      them from <bareword>s and the components of <fqdn>s which are
      traditionally in lower case.

In the following examples, "upstream.example.com" is a site which has
just sent an article (or so it is claimed) to "downstream.example.com".
"123.123.123.123" is the IP address from which downstream received it,
which may or may not be the IP address of upstream. The examples show the
full <path-entry> inserted by downstream, followed by (at least the start
of) the <path-entry> inserted by upstream.
 
1. downstream.example.com!123.123.123.123..SEEN!upstream.example.com...
2. downstream.example.com!123.123.123.123..MISMATCH!upstream.example.com...
3. downstream.example.com!123.123.123.123..MATCH!upstream.example.com...
4. downstream.example.com!!upstream.example.com...
5. downstream.example.com!upstream.example.com...
 
All the diagnostic <source-entry>s are immediately distinguishable from
the <path-entry>s by the presence of a big uppercase keyword.
 
Even if you thought 123.123.123.123 was a site to which you were not
supposed to send articles, no current implementation would recognize it as
such in any of those examples (though that would not be the case with
the version 1 syntax).
 
Ex1. Downstream recorded that 123.123.123.123 was the source of the
article "just for the hell of it". It makes no claim to have verified that
it belonged to upstream.
 
Ex2. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it no way matched any known address associated
with upstream. Some current practice uses almost exactly that notation.

Ex3. Downstream recorded that 123.123.123.123 was the source of the
article and asserted that it was indeed a known address used by upstream.
In which case you may ask why it bothered to clutter the Path by quoting
it in full.

Ex4. Downstream noted the IP (whatever) of the source and asserts that it
was indeed a known address used by upstream. But it did not clutter the
Path with unnecessary detail. That is the notation intended for normal
use.

Ex5. Downstream made no checks and makes no assertions. That is
essentially current practice which we hope will be replaced by Ex4 over
time.

NOTE: The use of an IP address for the <source-entry> in the examples
does not imply that a corresponding <fqdn> or <bareword> could not have
been used instead (indeed, it would be more user-friendly to have done
so). So Ex3 could as well have been written:

3. downstream.example.com!upstream.example.com..MATCH!upstream.example.com...

-- 
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

To: [email-masked]
Xref: clerew local.usefor:22708
Newsgroups: local.usefor
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: #1047 - Paths in USEPRO
Date: Thu, 10 Nov 2005 20:43:43 GMT
Lines: 82
Sender: [email-masked]

Although not immediately relevant to USEFOR, Harald did ask us (on Sept
13th) to consider some related text in USEPRO, because it is closely
related to the syntax in USEFOR. Currently, my latest proposed text in
USEPRO contains 3 paragraphs telling you how to construct a
<path-identity> using
   1. an <fqdn>
   2. an IP address
   3. a <bareword>

Since we have decided to disallow IP addresses in <path-identity>s (they
are now only allowed in <souce-identity>s, aka diagnostics), that second
parapgraph has to come out.

Harald therefore proposed the following:

<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
[RFC2821]; 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.

...

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

His #1 is broadly the same as my #1, but his #2 introduces the possibility
of an FQDN that does not resolve to anything.

I was not happy about that (though it has been seen in the Real World).
Nobody else has expressed an opinion that I can recall, so we are stuck
without a decision.

So I propose a compromise as follows:
   a) we say in #1 that the FQDN "SHOULD" resolve to something (maybe not
      mailable); I agree that the "MUST" implied by my original #1 was a
      bit strong - no great disaster strikes if it is violated.
   b) we are silent about the possibility of its not resolving to
      anything; so anyone who does that has violated a "SHOULD" and maybe
      caused inconvenience to somebody, but that is what goes with any
      "SHOULD" territory.

So #1 would now look like:

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).

Harald's #3 (which would then become #2) is virtually the same as mine:

3. Some other (arbitrary) name 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.

Is all that acceptable to everybody?

-- 
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