Subject: Re: Mandatory From field, anonymity, and hacks
From: Bruce Lilly <[email-masked]>
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 Jul 2004 17:37:29 -0400
List-Id: <ietf-822.imc.org>

Charles Lindsey wrote:
> 
> On Thu, 29 Jul 2004 22:51:35 -0400, Bruce Lilly <[email-masked]> wrote:

>> I do have the text, and there is no such "recommend[ation]".
> 
> 
> It says
> 
>       ".invalid" is intended for use in online construction of domain
>       names that are sure to be invalid and which it is obvious at a
>       glance are invalid.

That is not a recommendation for anything -- it is a statement of intent;
intent for use "online" and not via hard-coding -- and is certainly not
a recommendation for use in address fields.

>> You have missed the point.  Evidently you haven't looked at RFC
>> 3696.
> 
> 
> I have now looked at RFC 3696, and what Usefor proposes seems entirely 
> consistent with same. Essentially, it says that if you intend user
> agents  to check for and act upon particular TLDs, then you need to be
> pretty sure  that  your filtering is fully consistent with the relevant
> published  specifications. A registration with IANA that a given TLD
> will _never_  resolve to anything seems as clear in that regard as one
> can get.

You have utterly missed the point of RFC 3696. The point is that
hard-coding domain names is foolhardy; whether that is a hard-coded
assumption that TLDs are 3 characters, or that specific strings are or
are not TLDs, etc.  And you have far too much faith in IANA; RFC 2046
reserves the name "ASCII" which is not supposed to be used as a charset
name or alias -- yet IANA has registered it as a charset alias.  Now,
IANA doesn't control TLDs, ICANN does; whether you have more or less
faith in ICANN vs. IANA is another matter...

Date: Sat, 31 Jul 2004 21:58:13 +0100
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

On Thu, 29 Jul 2004 22:51:35 -0400, Bruce Lilly <[email-masked]> wrote:

>
> Charles Lindsey wrote:
>
>> Indeed, but "invalid DNS names" means, er, "invalid DNS names", and
>> "other  similar uses" should cover most other applications.
>
> No. Printed examples place no load on DNS, testing has negligible
> impact. Widespread use in messaging would place a large load on DNS.

I already explained that in reply to Keith. Naturally, agents that are  
minded to reply/followup to articles with .invalid TLDs in the from field  
need to check for the .invalid TLD. That should be obvious, and  
consequently the Usefor draft says 'Followup agents SHOULD NOT attempt to  
send email to any address ending in ".invalid"'.
>
>> And if you read further down in RFC 2606 (I don't have the exact words
>> in  front of me), you will see that it is recommended for use
>
> I do have the text, and there is no such "recommend[ation]".

It says

       ".invalid" is intended for use in online construction of domain
       names that are sure to be invalid and which it is obvious at a
       glance are invalid.

which is pretty much what I said (and you snipped), and is exactly the  
intent of what is currently proposed in the Usefor draft.
>
>>> Well, I might be inclined to prefer using a fixed, guaranteed  
>>> black-hole
>>> valid address if somebody wants to set one up...
>>
>>
>> It doesn't need setting up. The TLD ".invalid" already has the required
>> property
>
> Wrong. There is a huge difference between NXDOMAIN and an MX record that
> points to a server that discards messages.

>> No, I meant exactly what I said. If it is guaranteed, by IANA
>> registtration, that ".invalid" will never resolve, then agents need not
>> bother to try it.
>
> You have missed the point.  Evidently you haven't looked at RFC
> 3696.

I have now looked at RFC 3696, and what Usefor proposes seems entirely  
consistent with same. Essentially, it says that if you intend user agents  
to check for and act upon particular TLDs, then you need to be pretty sure  
that  your filtering is fully consistent with the relevant published  
specifications. A registration with IANA that a given TLD will _never_  
resolve to anything seems as clear in that regard as one can get.

-- 
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: Sat, 31 Jul 2004 16:45:01 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg list <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: ietf-822imcorg list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Charles Lindsey wrote:
> 
> On Fri, 30 Jul 2004 14:38:43 -0400, Keith Moore <[email-masked]> wrote:

>> that doesn't do a thing to keep the root servers from getting hit.
> 
> 
> It does if user agents that receive ill-considered requests to send
> mail  to such addresses recognize that particular case and don't waste
> time  looking it up.

That is exactly the sort of heuristic, based on a mere convention that
RFC 3696 cautions against.  Suppose RFC 2606 is superseded by another
RFC that changes ".invalid" to ".undefined", and permits ".invalid"
to become a valid TLD; what happens to implementations with hard-coded
checks for ".invalid"?

OTOH, glad to see that you recognize that use of ".invalid" in an
address field is "ill-considered".

Date: Sat, 31 Jul 2004 21:16:17 +0100
From: "Charles Lindsey" <[email-masked]>
To: "ietf-822imcorg list" <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

On Fri, 30 Jul 2004 14:38:43 -0400, Keith Moore <[email-masked]> wrote:

>
>
>> > Well, I might be inclined to prefer using a fixed, guaranteed  
>> black-hole
>> > valid address if somebody wants to set one up...
>>
>> It doesn't need setting up. The TLD ".invalid" already has the required
>> property, and is registered with IANA as being guaranteed never to  
>> resolve
>> to anything.
>
> that doesn't do a thing to keep the root servers from getting hit.

It does if user agents that receive ill-considered requests to send mail  
to such addresses recognize that particular case and don't waste time  
looking it up.

-- 
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: 30 Jul 2004 20:30:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Has IANA gone mad?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked]  wrote on 29.07.04 in <[email-masked]>:

> > Kai Henningsen wrote:
>
> > > I found out about the datatracker about a week ago, either from
> > > something here or possibly on [email-masked] - I don't remember exactly.
> > >
> > > It may have been discussed at length on various lists, but that
> > > obviously wasn't enough except for someone who was following one of
> > > those lists at that time. Which, it seems, didn't include me, or Bruce,
> > > or persumable a large number of other people.
>
> > It's certainly been discussed in some of the plenaries. Some ADs also
> > make a point of letting you know about it when your I-D gets to the
> > point of being tracked.
>
> And also during apps area sessions, if memory serves. I'm sure it has been
> covered in WG chair training as well, although I haven't been there to see
> it.
>
> Document authors receive automatic notification of tracker state changes
> for their documents. This may have been extended to WG chairs by now - I
> think that was the plan some time back.
>
> It was also announced on the main IETF announcement list back on 4-Nov-2002.
> Discussion has subsequently occured on that list and elsewhere.

Which pretty much proves my point. It explicitely gets told to a small  
number of people, and was discussed in a small number of places.

As a result, one should *expect* the general public to be uninformed.

Until, that is, links get prominently inserted on those web pages people  
often visit.

MfG Kai

Date: Fri, 30 Jul 2004 14:38:43 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

> > Well, I might be inclined to prefer using a fixed, guaranteed black-hole
> > valid address if somebody wants to set one up...
> 
> It doesn't need setting up. The TLD ".invalid" already has the required  
> property, and is registered with IANA as being guaranteed never to resolve  
> to anything.

that doesn't do a thing to keep the root servers from getting hit.

--
Regime change 2004 - For great justice.

Date: Fri, 30 Jul 2004 14:37:20 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

> I note that there are other protocols which depart from RFC 2822 much
> more  than Netnews does, with the full blessing of the IESG (SIP, for
> example).

there's nothing inherently wrong with borrowing good aspects of a proven
design for use in a new design.  but in the case of networking protocols
it does have a couple of drawbacks.  one is that people are continually
tempted to take features of one design and apply them to the other,
whether it makes sense or not.  (e.g. use of HTTP fields in MIME or vice
versa)  another drawback is the potential for confusion between the two
protocols.  

Date: Thu, 29 Jul 2004 21:43:22 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Kai Henningsen wrote:

> > I found out about the datatracker about a week ago, either from something
> > here or possibly on [email-masked] - I don't remember exactly.
> >
> > It may have been discussed at length on various lists, but that obviously
> > wasn't enough except for someone who was following one of those lists at
> > that time. Which, it seems, didn't include me, or Bruce, or persumable a
> > large number of other people.

> It's certainly been discussed in some of the plenaries. Some ADs also
> make a point of letting you know about it when your I-D gets to the
> point of being tracked.

And also during apps area sessions, if memory serves. I'm sure it has been
covered in WG chair training as well, although I haven't been there to see it.

Document authors receive automatic notification of tracker state changes
for their documents. This may have been extended to WG chairs by now - I think
that was the plan some time back.

It was also announced on the main IETF announcement list back on 4-Nov-2002.
Discussion has subsequently occured on that list and elsewhere.

				Ned

Date: Fri, 30 Jul 2004 00:29:25 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

Kai Henningsen wrote:

> I found out about the datatracker about a week ago, either from something  
> here or possibly on [email-masked] - I don't remember exactly.
> 
> It may have been discussed at length on various lists, but that obviously  
> wasn't enough except for someone who was following one of those lists at  
> that time. Which, it seems, didn't include me, or Bruce, or persumable a  
> large number of other people.

It's certainly been discussed in some of the plenaries. Some ADs also 
make a point of letting you know about it when your I-D gets to the 
point of being tracked.

	Tony Hansen
	[email-masked]

Date: Thu, 29 Jul 2004 22:51:35 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Charles Lindsey wrote:

> Indeed, but "invalid DNS names" means, er, "invalid DNS names", and
> "other  similar uses" should cover most other applications.

No. Printed examples place no load on DNS, testing has negligible
impact. Widespread use in messaging would place a large load on DNS.

> And if you read further down in RFC 2606 (I don't have the exact words
> in  front of me), you will see that it is recommended for use

I do have the text, and there is no such "recommend[ation]".

>> Well, I might be inclined to prefer using a fixed, guaranteed black-hole
>> valid address if somebody wants to set one up...
> 
> 
> It doesn't need setting up. The TLD ".invalid" already has the required 
> property

Wrong. There is a huge difference between NXDOMAIN and an MX record that
points to a server that discards messages.

>>> which can be aborted at once without any DNS search at all?
>>
>>
>> Gack. NOOOOO!  Please tell me you didn't just say what I think you said!
>> In such a case, the only reasonable behavior is to query DNS for an MX
>> record for "REMOVE-THIS.foo.com.invalid." [*].
> 
> 
> No, I meant exactly what I said. If it is guaranteed, by IANA 
> registtration, that ".invalid" will never resolve, then agents need not 
> bother to try it.

You have missed the point.  Evidently you haven't looked at RFC
3696.

[...]
>  then you are just pissing
> in  the wind.

"Pissing in the wind" as you put it, has the property of only
affecting a small number of people.  What you are proposing is
"pissing on the DNS", which has an undesirable effect on the\Internet infrastructure.

Date: Thu, 29 Jul 2004 22:36:26 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg list <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: ietf-822imcorg list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Charles Lindsey wrote:
> 
> On Mon, 26 Jul 2004 22:48:55 -0400, Keith Moore <[email-masked]> wrote:
> 
>>
>>
>> On Jul 26, 2004, at 10:40 PM, Bruce Lilly wrote:
>>
>>> As noted above, the most important thing is that the sender envelope
>>> address be usable.
>>
>>
>> in a news-to-mail gateway?  I think not.  the sender of a usenet
>> message  doesn't want to know whether some random recipient got the
>> message.
> 
> 
> I believe the normal practice in a news-to-mail gateway would be to set 
> the Sender address and the Return-Path to the gateway.

The Sender header field has nothing to do with the envelope sender, and
the Return-Path field is set on *final* delivery, not by gateways.

> Thank you for that. Bruce has been trying to say for months that
> Netnews  is just a special kind of mail

That is an outrageous lie; I have never said any such thing.

> I note that there are other protocols which depart from RFC 2822 much
> more  than Netnews does, with the full blessing of the IESG (SIP, for
> example).

SIP has nothing whatsoever to do with RFC 2822 Internet Message Format;
is is somewhat similar to HTTP, which it itself quite different from the
Internet Message Format.

Date: Thu, 29 Jul 2004 22:39:38 +0100
From: "Charles Lindsey" <[email-masked]>
To: [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

On Mon, 26 Jul 2004 23:16:57 -0400, Bruce Lilly <[email-masked]> wrote:

>
> Charles Lindsey wrote:
>
> [Concerning RFC 2606]
>
>> That says "can be used for private testing..., example in documentation,
>> DNS related experimentation, invalid DNS names, or other similar uses".  
>> I
>> think that is wide enough to cover the intended usage.
>
> DNS experimentation and testing are different matters from deliberate
> obfuscation (or worse).

Indeed, but "invalid DNS names" means, er, "invalid DNS names", and "other  
similar uses" should cover most other applications.

And if you read further down in RFC 2606 (I don't have the exact words in  
front of me), you will see that it is recommended for use when you want  
something that is immediately and obviously invalid, just from a casual  
inspection, which is exactly what is needed in the case under discussion.
>

> Well, I might be inclined to prefer using a fixed, guaranteed black-hole
> valid address if somebody wants to set one up...

It doesn't need setting up. The TLD ".invalid" already has the required  
property, and is registered with IANA as being guaranteed never to resolve  
to anything.
>
>>     From: Joe Doe <[email-masked]>
>>
>> which can be aborted at once without any DNS search at all?
>
> Gack. NOOOOO!  Please tell me you didn't just say what I think you said!
> In such a case, the only reasonable behavior is to query DNS for an MX
> record for "REMOVE-THIS.foo.com.invalid." [*].

No, I meant exactly what I said. If it is guaranteed, by IANA  
registtration, that ".invalid" will never resolve, then agents need not  
bother to try it.

Naturally if they do (whether for testing or anything else), they will  
still be told the same thing.
>
> Now consider an alternative to either:
> -------------------
> Subject: foo
> Date: 1 Jan 2005 12:34:56 +0700
>
> [body] I, Joe Doe, of Timbuktu (not to be confused with any other "Joe  
> Doe"),
> being of paranoid mind, do hereby write:  blah, blah, blah.

And do you think Joe Doe is ever going to do that, when he can more easily  
write (and his readers will more easily recognize, and followup/reply  
agents can more easily generate attribution lines for)

     From: Joe Doe <[email-masked]>

Indeed, From lines of that form are already becoming quite common on  
Usenet, and if you think you can stop them, then you are just pissing in  
the wind.

-- 
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, 29 Jul 2004 22:39:36 +0100
From: "Charles Lindsey" <[email-masked]>
To: "ietf-822imcorg list" <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

On Mon, 26 Jul 2004 22:48:55 -0400, Keith Moore <[email-masked]> wrote:

>
>
> On Jul 26, 2004, at 10:40 PM, Bruce Lilly wrote:
>
>> As noted above, the most important thing is that the sender envelope
>> address be usable.
>
> in a news-to-mail gateway?  I think not.  the sender of a usenet message  
> doesn't want to know whether some random recipient got the message.

I believe the normal practice in a news-to-mail gateway would be to set  
the Sender address and the Return-Path to the gateway.
>
>> Usenet news is an application of the RFC [2]822 Internet Message Format.
>
> no more than SMTP is an application of the FTP protocol.  in either case
> the two are similar but different protocols, with different syntax and
> semantics.  there are both advantages and disadvantages to having
> usenet and [2]822 so similar.
>
Thank you for that. Bruce has been trying to say for months that Netnews  
is just a special kind of mail that is bound by RFC 2822. Which is of  
course nonsense. They are different protocols, and the fact that Netnews  
tries to follow RFC 2822 whereever it can is that it makes good sense to  
do so, not because there is some law of the universe that says it must.

I note that there are other protocols which depart from RFC 2822 much more  
than Netnews does, with the full blessing of the IESG (SIP, for example).

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

Cc: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Mon, 26 Jul 2004 23:58:06 -0400
To: ietf-822imcorg list <[email-masked]>
Sender: [email-masked]

>>> In the case of an MUA, an invalid address will result in a 
>>> notification
>>> or bounce
>>
>> only if it's an envelope recipient address.
>
> No, MUAs often send raw message text to an executable transport agent
> (e.g. sendmail) which examines the message header to determine 
> recipients.

in that case, sendmail is performing part of the MUA's function.  
nothing says that the entire MUA has to be implemented in a single 
program.

>>> As noted above, the most important thing is that the sender envelope
>>> address be usable.
>>
>> in a news-to-mail gateway?
>
> No, for general gateways -- Usenet news has no equivalent of a sender
> envelope address, as noted.

it's easy to lose context in these kinds of discussions.  and when 
talking about gateways it's really important to consider these issues 
on a case-by-case basis, and carefully consider each case separately.

>>> Usenet news is an application of the RFC [2]822 Internet Message 
>>> Format.
>>
>>
>> no more than SMTP is an application of the FTP protocol.
>
> SMTP replaced FTP mail-specific commands(and the short-lived MTP) for
> transport of messages. The mail-specific FTP commands, MTP, and SMTP
> transport(ed) Internet Message Format content (RFCs 561, 680, 724, 733,
> 822, 2822).  As do POP (several versions), IMAP, NNTP, LMTP, and RFC 
> 2476
> submission protocol.  It's certainly true that NNTP is a different 
> protocol
> from SMTP, and both differ from POP (although there are similarities in
> those three, e.g. byte-stuffing), and all three of those differ from 
> IMAP.
> Nevertheless, they all transport Internet Message Format content.

nope.  that kind of overgeneralization just causes confusion.

Keith

Date: Mon, 26 Jul 2004 23:35:55 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg list <[email-masked]>
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: ietf-822imcorg list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Keith Moore wrote:
> 
> 
> On Jul 26, 2004, at 10:40 PM, Bruce Lilly wrote:
> 
>> Keith Moore wrote:
>>
>>> we don't expect native MUAs to go to great lengths to prevent invalid or
>>> unusable addresses from appearing messages. why should we impose this
>>> burden on gateways?
>>
>>
>> In the case of an MUA, an invalid address will result in a notification
>> or bounce
> 
> 
> only if it's an envelope recipient address.

No, MUAs often send raw message text to an executable transport agent
(e.g. sendmail) which examines the message header to determine recipients.
To send this message, I did not have to inform my MUA or any transport
software of envelope addresses; they were determined from the header
To and Cc fields.

>> As noted above, the most important thing is that the sender envelope
>> address be usable.
> 
> 
> in a news-to-mail gateway?

No, for general gateways -- Usenet news has no equivalent of a sender
envelope address, as noted.

>> Usenet news is an application of the RFC [2]822 Internet Message Format.
> 
> 
> no more than SMTP is an application of the FTP protocol.

SMTP replaced FTP mail-specific commands(and the short-lived MTP) for
transport of messages. The mail-specific FTP commands, MTP, and SMTP
transport(ed) Internet Message Format content (RFCs 561, 680, 724, 733,
822, 2822).  As do POP (several versions), IMAP, NNTP, LMTP, and RFC 2476
submission protocol.  It's certainly true that NNTP is a different protocol
from SMTP, and both differ from POP (although there are similarities in
those three, e.g. byte-stuffing), and all three of those differ from IMAP.
Nevertheless, they all transport Internet Message Format content.

Date: Mon, 26 Jul 2004 23:16:57 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Charles Lindsey wrote:
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>>And therein lies a problem, for that is not the intent of RFC 2026 in
>>making provision for a domain name for DNS testing purposes.
> 
> 
> RFC 2026 is titled "The Internet Standards Process". Perhaps you meant RFC
> 2606?

Yes, a typo.

> That says "can be used for private testing..., example in documentation,
> DNS related experimentation, invalid DNS names, or other similar uses". I
> think that is wide enough to cover the intended usage.

DNS experimentation and testing are different matters from deliberate
obfuscation (or worse).

> In any case, would you prefer a poster to use
> 
>     From: Joe Doe <[email-masked]>
> 
> (which involves a full DNS search each time someone tries to mail to it,
> because DNS failures are never cached),

Well, I might be inclined to prefer using a fixed, guaranteed black-hole
valid address if somebody wants to set one up... but you haven't proposed
that or even acknowledged that there might be alternatives other than the
two that you mention...

>     From: Joe Doe <[email-masked]>
> 
> which can be aborted at once without any DNS search at all?

Gack. NOOOOO!  Please tell me you didn't just say what I think you said!
In such a case, the only reasonable behavior is to query DNS for an MX
record for "REMOVE-THIS.foo.com.invalid." [*].  If you're suggesting that
software should recognize ".invalid" and avoid a DNS lookup, you are a
sinner; for penitence you must read the scripture of John (Klensin),
chapter 3696, verses 1, 2, and 6.  Seriously, if developers start hard-
coding ".invalid" into places where they should be querying DNS, that
completely negates the entire point of having a known invalid TLD *for*
*testing* -- short-circuiting the ability to test DNS by hard-coding
magic cookies is absolutely the wrong thing to do.  Please don't even
suggest doing so as a jest.

Now consider an alternative to either:
-------------------
Subject: foo
Date: 1 Jan 2005 12:34:56 +0700

[body] I, Joe Doe, of Timbuktu (not to be confused with any other "Joe Doe"),
being of paranoid mind, do hereby write:  blah, blah, blah.
--------------------

I.e. No From header field (and no Reply-To). No load on DNS at all. No
ability to reply via email, of course, but that is also the case with an
invalid address (and w/o the overhead and annoyance of attempts, bounces,
DSNs, etc.).  That is the proposal on the table.

* followed by MX queries for "foo.com.invalid.", "com.invalid.", and
"invalid.".  Which is clearly one more query than would be required
w/o the ".invalid" suffix; so in answer to your question, yes, of the two
alternatives that you mention, and w/o consideration of any other
alternatives, I would prefer the version w/o ".invalid" as it places a
lesser burden on DNS.

Cc: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Mon, 26 Jul 2004 22:48:55 -0400
To: ietf-822imcorg list <[email-masked]>
Sender: [email-masked]

On Jul 26, 2004, at 10:40 PM, Bruce Lilly wrote:

> Keith Moore wrote:
>
>> we don't expect native MUAs to go to great lengths to prevent invalid 
>> or
>> unusable addresses from appearing messages. why should we impose this
>> burden on gateways?
>
> In the case of an MUA, an invalid address will result in a notification
> or bounce

only if it's an envelope recipient address.

>> when gateways have to translate addresses from one format to another 
>> (as
>> they do between X.400 and internet mail), they should make sure that 
>> the
>> resulting addresses are valid syntax.  this is just sanity checking.
>> the reason it's necessary is that there are usually some addresses 
>> that
>> cannot be translated. but that's not the same thing as ensuring that 
>> the
>> address is valid.
>
> As noted above, the most important thing is that the sender envelope
> address be usable.

in a news-to-mail gateway?  I think not.  the sender of a usenet 
message doesn't want to know whether some random recipient got the 
message.

>> rather than trying to fix internet mail to
>> accommodate a bad idea in Usenet, maybe the Usenet people need to come
>> up with a better idea.
>
> Usenet news is an application of the RFC [2]822 Internet Message 
> Format.

no more than SMTP is an application of the FTP protocol.  in either case
the two are similar but different protocols, with different syntax and
semantics.  there are both advantages and disadvantages to having
usenet and [2]822 so similar.

Date: Mon, 26 Jul 2004 22:40:16 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg list <[email-masked]>
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: ietf-822imcorg list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Keith Moore wrote:

> we don't expect native MUAs to go to great lengths to prevent invalid or
> unusable addresses from appearing messages. why should we impose this
> burden on gateways?

In the case of an MUA, an invalid address will result in a notification
or bounce, which can be handled by the sender (for example, see RFC 2476
section 3.2).  In the case of a gateway in general, the same applies only
if both of the following conditions are met:
1. the non-Internet-mail side of the gateway has the equivalent of a
   sender envelope address
2. the gateway is able to translate that sender envelope address into
   one which is valid and usable from the Internet mail environment

Neither condition applies in the case of a Usenet news-to-mail gateway.

> when gateways have to translate addresses from one format to another (as
> they do between X.400 and internet mail), they should make sure that the
> resulting addresses are valid syntax.  this is just sanity checking. 
> the reason it's necessary is that there are usually some addresses that
> cannot be translated. but that's not the same thing as ensuring that the
> address is valid.

As noted above, the most important thing is that the sender envelope
address be usable. Then if there's a problem with delivery, the sender
can be informed of that fact. Next in importance would probably be
Disposition-Notification-To address if the field is present and if the
gateway and non-Internet-mail environment both support the equivalent
of disposition notifications.  Following that would be recipient
envelope address; if the message cannot be delivered to the recipient(s),
nothing that follows below matters much.  Next would be Reply-To
addresses if the non-Internet-mail side supports the equivalent and if
it is present.  The From field would be of lower importance still. To,
Cc, and Bcc header fields are of lowest importance, but they are
optional (unlike From).

> [...] creating a new TLD to indicate an invalid address is probably a bad
> idea even within Usenet.

Agreed. [that is a separate issue from having a known invalid TLD for
the purpose of being able to test DNS application software's handling
of nonexistent domains. Indeed, there may be justification for having
a reserved second-level, guaranteed-invalid domain name component for
the purpose of being able to test DNS implementations (not to mention
certain registrars' behavior) w.r.t. nonexistent domain names under
TLSs such as, oh I don't know,  maybe "com" or "net".  But I digress.]

> rather than trying to fix internet mail to
> accommodate a bad idea in Usenet, maybe the Usenet people need to come
> up with a better idea.

Usenet news is an application of the RFC [2]822 Internet Message Format.
As of this time, that format requires a From field.  There exist news-to-
mail gateways, and as of this time RFC 2821 places certain requirements
on such gateways.  The combination makes standardization of use of the
.invalid TLD hack in addresses via a proposed Standards Track RFC worse
that a"a bad idea"; it's a non-starter.  So what are the alternatives?
I have proposed making the From header field optional.  That permits a
sender -- not only in Usenet news, but in general -- to omit that field
for whatever purpose suits the sender (anonymity to avoid fascist
repression, to avoid address harvesting by spammers, etc.).  According
to my reading of RFC 2821, it does not require any changes to RFC 2821 [*].
But it does provide an option for gateway implementors who care about
RFC 2821 conformance in the event of an invalid From field mailbox in
cases (such as Usenet news) where there is no equivalent of a sender
envelope address for the purpose of punting the problem back to the
sender.  As noted above, the proposal has application apart from the
Usenet news and/or gateway issues.  I believe that making From optional
is "a better idea".  If somebody foresees a problem with it, I'd like
to hear about it.  Likewise, if somebody has an equally good or better
idea, I'm open to it.

* However if the RFC 2821 requirement is relaxed, it does not adversely
affect the proposal.

To: [email-masked]
Xref: clerew local.mime:3182
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Mon, 26 Jul 2004 21:17:45 GMT
Lines: 19
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>tcreating a new TLD to indicate an invalid address is probably a bad 
>idea even within Usenet.  rather than trying to fix internet mail to 
>accommodate a bad idea in Usenet, maybe the Usenet people need to come 
>up with a better idea.

But we haven't created a new TLD. It already exists (RFC 2606).

-- 
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.mime:3179
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Mon, 26 Jul 2004 10:50:05 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>regarding gateways - in general the job of the gateway is to preserve 
>the semantics of the original message into the destination environment. 
>  the job of the gateway is NOT to correct errors in the original 
>message.

Exactly so, which is why I found the requirement in RFC 2821 which says
you MUST correct that particular error so strange.

I honestly think it would be better for gateway implementors simply to
ignore that requirement. There is no way to enforce it anyway. But I would
still be curious to hear what such implementors actually currently do.

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

Cc: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Mon, 26 Jul 2004 00:30:44 -0400
To: ietf-822imcorg list <[email-masked]>
Sender: [email-masked]

>> regarding gateways - in general the job of the gateway is to preserve
>> the semantics of the original message into the destination 
>> environment.
>>  the job of the gateway is NOT to correct errors in the original 
>> message.
>
> Well, that's an issue with the RFC 2821 text, which ought to be up for
> review Real Soon Now.  It seems that the intent of RFC 2821 is that 
> e.g.
> in the case of an X.400 to Internet mail gateway, the address on the
> Internet side should be a valid and usable Internet address.

it's pretty difficult to write useful general specifications for 
gateway behavior. it's hard enough to write specifications for a 
specific case like X.400 to Internet mail.  trying to make every bit of 
RFC 2821bis apply to gateways is probably a fool's errand.

we don't expect native MUAs to go to great lengths to prevent invalid 
or unusable addresses from appearing messages. why should we impose 
this burden on gateways?

when gateways have to translate addresses from one format to another 
(as they do between X.400 and internet mail), they should make sure 
that the resulting addresses are valid syntax.  this is just sanity 
checking.  the reason it's necessary is that there are usually some 
addresses that cannot be translated. but that's not the same thing as 
ensuring that the address is valid.

tcreating a new TLD to indicate an invalid address is probably a bad 
idea even within Usenet.  rather than trying to fix internet mail to 
accommodate a bad idea in Usenet, maybe the Usenet people need to come 
up with a better idea.

Date: Sun, 25 Jul 2004 15:31:29 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg list <[email-masked]>
Organization: Bruce Lilly
To: Keith Moore <[email-masked]>
CC: ietf-822imcorg list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Keith Moore wrote:
> 
>>
>>> The mailboxes (N.B. no named groups) in the From field are used for
>>> replies
>>> (in the absence of a Reply-To field).  So a hypothetical From field with
>>> no mailbox is unworkable in the absence of a Reply-To field, and is
>>> pointless in the presence of a Reply-To field.

> also, From is _not_ pointless in the presence of reply-to because a
> recipient might prefer to reply to the author of the message rather than
> to the address where the author of that message set reply-to.

True, but not quite relevant to what was claimed, viz. that a hypothetical
>From field w/ no usable address is pointless.  If (contrary to RFC 2821)
it is unuseable for replies, then obviously one cannot use it to reply to
the author (Reply-To notwithstanding).

> regarding gateways - in general the job of the gateway is to preserve
> the semantics of the original message into the destination environment.
>  the job of the gateway is NOT to correct errors in the original message.

Well, that's an issue with the RFC 2821 text, which ought to be up for
review Real Soon Now.  It seems that the intent of RFC 2821 is that e.g.
in the case of an X.400 to Internet mail gateway, the address on the
Internet side should be a valid and usable Internet address.  The question
at hand is what should a Usenet news-to-mail gateway do in the presence of
a bogus address (or conversely, should Usenet news, which is an application
of the RFC 2822 Internet Message Format, condone or encourage unusable and
invalid pseudo-addresses in the From field).  As 2821 stands, such a
gateway is required to ensure that addresses are valid and useful for
replies.  As it stands, that effectively precludes Usenet news from condoning
or encouraging invalid and/or unusable addresses. A relaxation of 2821
would affect other types of gateways (e.g. X.400 to Internet mail) as
well.

The current RFC 2822 requirement for a From field provides no opportunity
for anonymous messages, and has led to the sort of hacks that usefor
drafts coondine and encourage.  IT seems to me that relaxing the 2822
requirement provides relief for those desiring anonymity while retaining
the 2821 requirement that addresses in field which are present be valid
and usable (e.g. usable conversion of X.400 addresses).

Cc: Keith Moore <[email-masked]>, ietf-822imcorg list <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Sun, 25 Jul 2004 09:22:28 -0400
To: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

>
>> The mailboxes (N.B. no named groups) in the From field are used for 
>> replies
>> (in the absence of a Reply-To field).  So a hypothetical From field 
>> with
>> no mailbox is unworkable in the absence of a Reply-To field, and is
>> pointless in the presence of a Reply-To field.
>
> On the contrary, it is not at all unworkable in News and mailing 
> lists. It
> simply encourages people to reply to the group/mailing list rather 
> than to
> the poster, which is actually not such a bad thing.

not when the sender manually chooses to direct replies there.  it is a 
bad thing when the list mungs reply-to.

also, From is _not_ pointless in the presence of reply-to because a 
recipient might prefer to reply to the author of the message rather 
than to the address where the author of that message set reply-to.  
reply-to is set based on the author's assumptions about what kind of 
replies are likely, but sometimes the recipient wants to reply for 
other reasons.

regarding gateways - in general the job of the gateway is to preserve 
the semantics of the original message into the destination environment. 
  the job of the gateway is NOT to correct errors in the original 
message.

Date: 25 Jul 2004 11:26:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
cc: [email-masked]
Subject: Re: Has IANA gone mad?
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked]  wrote on 24.07.04 in <[email-masked]>:

> Bruce, I'm afraid I find your position to be totally without merit,
> preposterous, and absurd. I also find your apparent ignorance of the IETF
> process and the tools used to support that process to be nothing short of
> appalling. Things like the RFC Editor queue and the datatracker were
> introduced years ago with not inconsiderable fanfare. They have also been
> discussed at great length on various lists.

(Note that I do not support Bruce.)

Well, I always thought I was pretty well informed about the general IETF  
way of things.

I found out about the RFC editor queue from the RFC editor pages.

I found out about the datatracker about a week ago, either from something  
here or possibly on [email-masked] - I don't remember exactly.

It may have been discussed at length on various lists, but that obviously  
wasn't enough except for someone who was following one of those lists at  
that time. Which, it seems, didn't include me, or Bruce, or persumable a  
large number of other people.

MfG Kai

To: [email-masked]
Xref: clerew local.mime:3175
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Date: Sat, 24 Jul 2004 21:29:56 GMT
Lines: 168
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Charles Lindsey wrote:

>> Yes, we had long discussions about this in the USEFOR WG. The feeling was
>> that 'munging' addresses for spam avoidance was a Bad Thing, and that the
>> only socially acceptable thing was to use your genuine email address. But
>> we had to face the fact that people were going to do it anyway. OTOH, we
>> could not openly condone or deprecate the practice in a standards track
>> document.

>Two questions, based on the following text in an approved Standards Track
>RFC (viz. RFC 2821):

>3.8.4 Other Header Fields in Gatewaying

>   The gateway MUST ensure that all header fields of a message that it
>   forwards into the Internet mail environment meet the requirements for
>   Internet mail.  In particular, all addresses in "From:", "To:",
>   "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
>   822 syntax, MUST reference only fully-qualified domain names, and
>   MUST be effective and useful for sending replies.

I find that last sentence rather odd, because the stated aim of that
paragraph is to meet the requirements for internet mail, and yet having a
bogus From field is only a SHOULD NOT in RFC 2822, which hardly justifies
that final MUST.

>Question 1: Why do you believe that the practice of using invalid
>addresses cannot be "openly" deprecated in a Standards Track document
>(N.B. "MUST be effective and useful" above, which goes well beyond
>mere deprecation of ineffective and/or unusable addresses)?

Because munging of From addresses on Usenet is a current social
phenomenon, and standards would do well not to interfere in social issues.
In any case, it is going to happpen whatever the standard says.

>Question 2: Since the text above places specific requirements on gateways
>into the mail environment, _specifically_ and _in_ _detail_ how do you
>propose that an invalid mailbox in a (mandatory per RFC 2822) From field
>would be converted by a news-to-mail gateway into an "effective and useful"
>mailbox in accordance with the mandatory requirements of RFC 2821
>section 3.8.4? [note that there is no provision in the syntax of the
>field for no mailbox]

I have no idea, but a useful first question would be "what happens at the
moment?". My suspicion is that current news-to-mailing-list gateways
simply ignore that bit of RFC 2821. Can you please point me to one that
does takes positive action in this matter - it would be interesting to see
what it actually does?

>> What we did, therefore, was to use wording, essentially the same as RFC
>> 2822, that the From address should be the email address of the
>> author/poster.

>That is *NOT* what RFC 2822 says!

It looks pretty close to the RFC 2822 wording to me, though we did not go
as far as that SHOULD.

>> But we then added that if the poster should "for whatever
>> reasons" wish to use a non-working email address, then he SHOULD use a
>> domain ending in ".invalid".

>And therein lies a problem, for that is not the intent of RFC 2026 in
>making provision for a domain name for DNS testing purposes.

RFC 2026 is titled "The Internet Standards Process". Perhaps you meant RFC
2606?

That says "can be used for private testing..., example in documentation,
DNS related experimentation, invalid DNS names, or other similar uses". I
think that is wide enough to cover the intended usage.

In any case, would you prefer a poster to use

    From: Joe Doe <[email-masked]>

(which involves a full DNS search each time someone tries to mail to it,
because DNS failures are never cached), or would you prefer

    From: Joe Doe <[email-masked]>

which can be aborted at once without any DNS search at all?

>>>Making the From header field optional would eliminate the need
>>>for such hacks
>>>by persons who desire the degree of anonymity that such hacks
>>>provide; those
>>>persons could simply avoid including a From field at all, rather than
>>>including a hacked bogus address in a From field.
>> 
>> 
>> But that does not really solve the problem.

>It solves the problem faced by gateway implementors upon encountering
>the ineffective and invalid addresses explicitly condoned by your
>draft; implementors could drop the invalid/ineffective addresses and
>if no addresses remain, then drop the field.

Which would mean that the message arrived on the mailing list with no
indication at all of who had posted it. I am sure that would be _most_
popular with the other members of that mailing list - NOT.

>> People still want to identify
>> themselves (and their readers certainly want to know who is writing to
>> them, whether in News or Email).

>How do you propose differentiating one "John Doe" from another "John Doe"
>in the absence of an email address?

I don't. I prefer to see the munged address (I doubt both Joe Does use the
same email address, munged or not). I see lots of munged addresses in the
groups I read, and I never have a problem recognizing familiar posters,
except when they are deliberately trying to mislead.

>  For what practical purpose would
>such a non-identifying "identity" be used?

I suggest you read some newsgroups regularly, and then you would know. It
ain't (particularly) broke. Stop trying to fix it.

>The mailboxes (N.B. no named groups) in the From field are used for replies
>(in the absence of a Reply-To field).  So a hypothetical From field with
>no mailbox is unworkable in the absence of a Reply-To field, and is
>pointless in the presence of a Reply-To field.

On the contrary, it is not at all unworkable in News and mailing lists. It
simply encourages people to reply to the group/mailing list rather than to
the poster, which is actually not such a bad thing.

>> but I think I would prefer to make people use
>> something ugly like the ".invalid" thing just to prevent it from becoming
>> a thing that everybody did as a matter of course

>What exactly do you think people who are now inclined to use bogus
>mailboxes in From fields will do?
>a) ignore your recommendation (in which case it is pointless)
>b) use effective and valid mailboxes (in which case why not simply require that)
>c) inappropriately use .invalid just because you say so, causing massive
>   problems for gateway implementors

a) leads to unnecessary DNS traffic. Moreover, people trying to mail to
the bad address usually get no immediate warning - just a bounce sometime
later.
b) is not going to happen, whatever we say.

which leaves c) as the best of a bad bunch.

>It seems to me that the likely outcomes would be a and/or c, and it is
>clear that you have not considered the implications for gateway
>implementation.

And I doubt many current gateway implementors are even aware of the eevil
thing they are doing.

-- 
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: Sat, 24 Jul 2004 09:12:49 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Bruce Lilly <[email-masked]>
Cc: [email-masked], "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Sender: [email-masked]

> > There are drafts and then there are drafts. Referencing a random draft
> > that Joe Blow put out there is one thing, referencing a draft that has been
> > approved for publication as an RFC is quite another. An approved draft in
> > effect _is_ a standard; it just hasn't completed the publication process yet.

> From the point of view of being able to say RFC NNNN section W.X.Y.Z says
> foo is prohibited/required, a draft is a draft and there is no RFC until
> there is an assigned RFC number.

But there is a document that has been approved at some standard level. Standard
!= RFC.

> > I note in passing that it is easy to determine the status of any draft;
> > this is what the datatracker is for.

> I have no idea who this Darth Racker person is :-).  I know about the
> rfc-index on the isi.edu ftp site.  If RFC 3232 hadn't superseded
> the Assigned Numbers RFC with the IANA web-based "database" that prompted
> this discussion, I'd still be checking RFC XX00 (RFC 1700 successor)
> for the relevant assigned numbers.  I haven't looked at the IESG home
> page in probably a year or more -- why should I; I haven't seen any RFC
> listed in the rfc-index declaring the rfc-index obsolete.

Sigh. Nobody ever claimed that the RFC Index is obsolete, only that it
doesn't tell the whole story. Reductio ad absurdum weakens your
argument, it does not strengthen it.

> > so if you're going to get tense about stuff changing on you,
> > you'd best not touch anything that hasn't made it to standard status.

> Change isn't the problem, it's having (or not having) a stable
> document which can be referenced w.r.t. specific requirements and/or
> prohibitions (recommendations, etc.).

You're missing the point. An approved draft is a document that isn't
supposed to change in any significant way prior to publication as
an RFC. Cases where changes have occurred are much rarer than cases
where an RFC is obsoleted by something that's substantially different
than the original.

> Since "published RFCs never
> change" (except when they're revised via errata), an RFC may be
> referenced, whereas referring to a draft is verboten.

And if this concerns you you should wait until the RFC is out.

> > First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard
> > back in October, 2003. (I again note that you could have determined this by
> > checking the datatracker.)

> Again, I know nothing about "datatracker", and judging by recent comments
> here, I'm not the only one. [And putting a link on some obscure web page isn't
> likely to change that.]

The other comments, such as they are, were from people concerned that it was
hard to find the tracker page. They most certainly weren't ignorant of its
existance, as apparently you were.

> If the draft was approved, what is its RFC number?

You are being absurd again. Approval of documents has never coincided with RFC
publication for at least as long as I've been a participant in the IETF - that
is, since 1989. Maybe it did before that - I wouldn't know.
 
> > Drafts approved for publication do not expire; the
> > notion that this registration was based on a draft that has now expired is
> > totally  bogus.

> So drafts expire after six months except when they don't. Okaaaaay...

It most certainly is OK, your sarcasm notwithstanding. And when the document is
published the draft is replaced with a tombstone pointing at the published RFC.

> And when something suddenly appears in the IANA registry with no reference
> in the rfc-index, all there is is (maybe) some draft which nobody is
> supposed to refer to because "drafts are not standards".  No RFC number to
> refer to.

> > Second, this document is currently in 48 hour author review (a fact you could
> > have easily determined by checking the RFC Editor queue), so its publication is
> > imminent.

> I see no mention of any "queue" in the rfc-index.

Your ignorance of the process the RFC Editor has been using for quite a while
now doesn't do your argument any good.

> And today, well over 48
> hours after your message, I still see no RFC corresponding to either the
> CPIM or msgtrk drafts in the latest rfc-index.  So not only do we apparently
> have a different concept of "fairly short order", but also of "48 hours"
> and/or "imminent".

Once the RFC is complete the RFC Editor asks authors for review. The review is
supposed to be done within 48 hours. However, since this is a volunteer
organization the RFC Editor has no ability to insist on timely review. Rather
than published something that the authors haven't had a chance to look at
(which has been shown over and over and over again to result in documents full
of errors), the RFC Editor generally will extend the period as needed.
Additionally, if the author finds typographical errors in the draft the token
goes back to the RFC Editor to deal with the errors. So the final step can take
longer in some cases.

> > If the trend you refer to is the immediate appearance of IANA registrations of
> > stuff that appears in approved drafts, it is a trend I for one would love to
> > see continue, regardless of the time it takes for the drafts the registry
> > refers to to complete the publication process.

> The trend is the departure from the situation prior to the discontinuation
> of the Assigned Numbers RFC, where the assigned numbers could be easily
> referenced back to a published RFC.   The change to a web-based conglomeration
> has happened, and I have adapted -- despite many seemingly irrelevant changes
> to formatting, inconsistencies (text files for some items, HTML for others,
> etc.), spurious changes to the modification dates with no substantive change
> to the content, etc.  However, the appearance of registered magic "numbers"
> prior to publication of an RFC that can be referenced is a great departure
> from the situation that existed when the Assigned Numbers RFC was periodically
> published.

Bruce, I'm afraid I find your position to be totally without merit,
preposterous, and absurd. I also find your apparent ignorance of the IETF
process and the tools used to support that process to be nothing short of
appalling. Things like the RFC Editor queue and the datatracker were introduced
years ago with not inconsiderable fanfare. They have also been discussed at
great length on various lists.

In any case, I no longer have time to waste on this silly arugment, so this
will be my final message on the topic.

				Ned

Date: Fri, 23 Jul 2004 23:59:56 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: "'ietf-822 mailing list'" <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
CC: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

[email-masked] wrote:

> There are drafts and then there are drafts. Referencing a random draft
> that Joe Blow put out there is one thing, referencing a draft that has been
> approved for publication as an RFC is quite another. An approved draft in
> effect _is_ a standard; it just hasn't completed the publication process yet.

>From the point of view of being able to say RFC NNNN section W.X.Y.Z says
foo is prohibited/required, a draft is a draft and there is no RFC until
there is an assigned RFC number.

> I note in passing that it is easy to determine the status of any draft;
> this is what the datatracker is for.

I have no idea who this Darth Racker person is :-).  I know about the
rfc-index on the isi.edu ftp site.  If RFC 3232 hadn't superseded
the Assigned Numbers RFC with the IANA web-based "database" that prompted
this discussion, I'd still be checking RFC XX00 (RFC 1700 successor)
for the relevant assigned numbers.  I haven't looked at the IESG home
page in probably a year or more -- why should I; I haven't seen any RFC
listed in the rfc-index declaring the rfc-index obsolete.

> so if you're going to get tense about stuff changing on you,
> you'd best not touch anything that hasn't made it to standard status.

Change isn't the problem, it's having (or not having) a stable
document which can be referenced w.r.t. specific requirements and/or
prohibitions (recommendations, etc.). Since "published RFCs never
change" (except when they're revised via errata), an RFC may be
referenced, whereas referring to a draft is verboten.  To give
more perspective on the situation, I have no problem in referring
to 30-year-old RFCs where appropriate (it is occasionally necessary
to read old email, for example) with confidence that the referenced
RFC hasn't changed since publication (modulo published errata), and
that the referenced RFC is available to anybody who cares to refer to
it (modulo hard disk crashes at ISI).

> I see nothing unusual about it, nor do I see any problem with such an
> implementation being based on an approved draft.

Until publication, there's no RFC number to refer to.  And the draft is
ephemeral; it is (theoretically) removed after 6 months.  A  validating
parser validates according to a collection of specifications and in
the event of a violation of some provision, it is desirable (to say the
least) to refer to the particular specification which applies. For example,
while RFC 2822 has no requirement w.r.t. the number of message header fields
specifying recipients, RFCs 822, 733, and 724 do/did require at least one of
To, Cc, or Bcc header fields. And as you know, MIME message/rfc822 has
yet a different set of requirements.  It does no good (ignoring the prohibition
against referring to drafts for the moment) to refer to draft-foo-bar-baz-MM
as a specification, not only because that specification might change, but
also because it may be unavailable in future to those who wish to consult
that reference.

> First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard
> back in October, 2003. (I again note that you could have determined this by
> checking the datatracker.)

Again, I know nothing about "datatracker", and judging by recent comments
here, I'm not the only one. [And putting a link on some obscure web page isn't
likely to change that.]  If the draft was approved, what is its RFC
number?

> Drafts approved for publication do not expire; the
> notion that this registration was based on a draft that has now expired is
> totally  bogus.

So drafts expire after six months except when they don't. Okaaaaay...
And when something suddenly appears in the IANA registry with no reference
in the rfc-index, all there is is (maybe) some draft which nobody is
supposed to refer to because "drafts are not standards".  No RFC number to
refer to.

> Second, this document is currently in 48 hour author review (a fact you could
> have easily determined by checking the RFC Editor queue), so its publication is
> imminent.

I see no mention of any "queue" in the rfc-index. And today, well over 48
hours after your message, I still see no RFC corresponding to either the
CPIM or msgtrk drafts in the latest rfc-index.  So not only do we apparently
have a different concept of "fairly short order", but also of "48 hours"
and/or "imminent".

> If the trend you refer to is the immediate appearance of IANA registrations of
> stuff that appears in approved drafts, it is a trend I for one would love to
> see continue, regardless of the time it takes for the drafts the registry
> refers to to complete the publication process.

The trend is the departure from the situation prior to the discontinuation
of the Assigned Numbers RFC, where the assigned numbers could be easily
referenced back to a published RFC.   The change to a web-based conglomeration
has happened, and I have adapted -- despite many seemingly irrelevant changes
to formatting, inconsistencies (text files for some items, HTML for others,
etc.), spurious changes to the modification dates with no substantive change
to the content, etc.  However, the appearance of registered magic "numbers"
prior to publication of an RFC that can be referenced is a great departure
from the situation that existed when the Assigned Numbers RFC was periodically
published.

From: "Scott Hollenbeck" <[email-masked]>
To: <[email-masked]>, "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: RE: Has IANA gone mad?
Date: Fri, 23 Jul 2004 11:22:44 -0400
Importance: Normal
Sender: [email-masked]

> Yes, well, I've passed your concern about this on in the 
> past. The response was
> to add a link at the top of the IESG Activities/Actions page, 
> the logic being
> that the status tracker is an IESG entity. (I note that a 
> link to the RFC
> Editor queue appears in a similar position under the "RFC 
> Pages" link.) I
> personally would prefer to have a link on the main IETF page 
> but nobody else
> seems to think this is appropriate.

FWIW there's now a link on the Internet-Drafts page:

http://www.ietf.org/ID.html

-Scott-

Date: Fri, 23 Jul 2004 10:05:54 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822mailing list <[email-masked]>
Organization: Bruce Lilly
To: Charles Lindsey <[email-masked]>
CC: ietf-822mailing list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

Charles Lindsey wrote:

> Yes, we had long discussions about this in the USEFOR WG. The feeling was
> that 'munging' addresses for spam avoidance was a Bad Thing, and that the
> only socially acceptable thing was to use your genuine email address. But
> we had to face the fact that people were going to do it anyway. OTOH, we
> could not openly condone or deprecate the practice in a standards track
> document.

Two questions, based on the following text in an approved Standards Track
RFC (viz. RFC 2821):

3.8.4 Other Header Fields in Gatewaying

   The gateway MUST ensure that all header fields of a message that it
   forwards into the Internet mail environment meet the requirements for
   Internet mail.  In particular, all addresses in "From:", "To:",
   "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC
   822 syntax, MUST reference only fully-qualified domain names, and
   MUST be effective and useful for sending replies.

Question 1: Why do you believe that the practice of using invalid
addresses cannot be "openly" deprecated in a Standards Track document
(N.B. "MUST be effective and useful" above, which goes well beyond
mere deprecation of ineffective and/or unusable addresses)?

Question 2: Since the text above places specific requirements on gateways
into the mail environment, _specifically_ and _in_ _detail_ how do you
propose that an invalid mailbox in a (mandatory per RFC 2822) From field
would be converted by a news-to-mail gateway into an "effective and useful"
mailbox in accordance with the mandatory requirements of RFC 2821
section 3.8.4? [note that there is no provision in the syntax of the
field for no mailbox]

> What we did, therefore, was to use wording, essentially the same as RFC
> 2822, that the From address should be the email address of the
> author/poster.

That is *NOT* what RFC 2822 says!

> But we then added that if the poster should "for whatever
> reasons" wish to use a non-working email address, then he SHOULD use a
> domain ending in ".invalid".

And therein lies a problem, for that is not the intent of RFC 2026 in
making provision for a domain name for DNS testing purposes.

>>Making the From header field optional would eliminate the need
>>for such hacks
>>by persons who desire the degree of anonymity that such hacks
>>provide; those
>>persons could simply avoid including a From field at all, rather than
>>including a hacked bogus address in a From field.
> 
> 
> But that does not really solve the problem.

It solves the problem faced by gateway implementors upon encountering
the ineffective and invalid addresses explicitly condoned by your
draft; implementors could drop the invalid/ineffective addresses and
if no addresses remain, then drop the field.

> People still want to identify
> themselves (and their readers certainly want to know who is writing to
> them, whether in News or Email).

How do you propose differentiating one "John Doe" from another "John Doe"
in the absence of an email address?  For what practical purpose would
such a non-identifying "identity" be used?  If there is some pressing
need to refer to an anonymous author by a pseudonym, why not simply use
"Anonymous Coward" or something similar (N.B. there is existing practice
on the Internet for doing exactly that)?

> So at least you need the <phrase> with
> the Real Name (which might actually be a pseudonym), and the From field is
> the proper place for that.

The mailboxes (N.B. no named groups) in the From field are used for replies
(in the absence of a Reply-To field).  So a hypothetical From field with
no mailbox is unworkable in the absence of a Reply-To field, and is
pointless in the presence of a Reply-To field.

> One might argue that the <address> part of the
> header could be omitted,

To, Cc, Bcc, and Reply-To address fields in the header are already optional,
and the Sender field is only required if the From field specifies more
than one mailbox.  So arguing "that the <address> part of the header
could be omitted" is the same as proposing that the From field be made
optional.  Nota Bene that prior to RFC 2822, at least one destination
field (To, Cc, Bcc) was required; dropping that requirement was a concession
to Usenet news, and in case you haven't guessed, I am proposing yet
another such concession.

> but I think I would prefer to make people use
> something ugly like the ".invalid" thing just to prevent it from becoming
> a thing that everybody did as a matter of course

What exactly do you think people who are now inclined to use bogus
mailboxes in From fields will do?
a) ignore your recommendation (in which case it is pointless)
b) use effective and valid mailboxes (in which case why not simply require that)
c) inappropriately use .invalid just because you say so, causing massive
   problems for gateway implementors

It seems to me that the likely outcomes would be a and/or c, and it is
clear that you have not considered the implications for gateway
implementation.

Date: Fri, 23 Jul 2004 08:48:35 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
CC: ietf-822imcorg <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

[email-masked] wrote:
> 
>>Arnt Gulbrandsen <[email-masked]> writes:

>>Note that X-No-Archive applies to the entire message.  The implications of
>>a Content-Disposition parameter that could be applied to arbitrarily
>>nested parts of a complex MIME message and not visible in the top-level
>>headers for an implementor trying to honor it are a bit troubling to me.
>>Without it being trivial to determine the archivability of a message, I
>>expect many archives wouldn't bother.
> 
> 
> Excellent point. A per-message archive: yes/no sort of field is something that
> can be implemented with minimal fuss in many cases and makes considerable sense
> as a suggestion to archival agents. Per-part archive suggestions, OTOH, are
> going to be a royal pain to implement: Consider the implications of marking all
> parts of a multipart as do-not-archive (do you then remove the multipart
> entirely?), the implications of marking one part that happens to be essential
> in a multipart/related (might as well drop the whole thing, but how do you know
> that?), what to do when a part of a signed message is removed, and so on. I
> certainly wouldn't bother to implement this mess.

There are details that ought to be specified in any case.  Even with an
overall per-message message header field, there ought to be a specification
for field semantics and handling if the message is split for transport
(via MIME message/partial).  Likewise for at least some instances of
message/external-body (most likely the specification would be that the
indication should be ignored in the MIME-part fields for
message/external-body, since most external-body access-types represent
some form of archive).

As noted by Arnt, the indication in any event is only a recommendation;
fretting over what to do about parts of multipart/related etc. is just
that; fretting.

If the semantics of a Content-Disposition field archive recommendation
parameter are defined to be meaningful only when applied to an entire
message (i.e. in the message header or in the MIME-part header of a
message type) then the "problem" of what do do for "per-part archive
suggestions" goes away -- ignore them except in the specific case where
the part in question is a message.

Ambiguity (in the absence of a clear specification of semantics and
applicability) about applicability of an archive recommendation will
exist if it appears in a MIME-part header whether it is in a MIME field
such as Content-Disposition, an extension field such as "Archive", or
a user-defined field such as "X-No-Archive".  However, handling of
MIME fields is already fairly well defined in the cases of message
splitting for transport (message/partial) and in MIME-part fields (in
particular, MIME fields are defined to have meaning in entities,
whereas non-MIME fields may be discarded at gateways; that has
ramifications for individual messages encapsulated as entities
within a MIME multipart/digest wrapper).

Date: Fri, 23 Jul 2004 07:46:22 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Lyndon Nerenberg <[email-masked]>
Cc: [email-masked], Bruce Lilly <[email-masked]>, "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Sender: [email-masked]

> --On 2004-7-19 11:23 PM -0700 [email-masked] wrote:

> > I note in passing that it is easy to determine the status of any
> > draft; this is what the datatracker is for.

> And I note in passing, for the UMPTEENTH time, that the bloody
> datatracker is buried in such a non-obvious place that expecting anyone
> to use it is pointless. (Use it? How on earth do you expect anyone to
> even FIND it?)

> Either put the bloody thing UP FRONT ON THE RFC AND ID pages at
> ietf.org, or burn it.

Yes, well, I've passed your concern about this on in the past. The response was
to add a link at the top of the IESG Activities/Actions page, the logic being
that the status tracker is an IESG entity. (I note that a link to the RFC
Editor queue appears in a similar position under the "RFC Pages" link.) I
personally would prefer to have a link on the main IETF page but nobody else
seems to think this is appropriate.

OTOH, there are these things called bookmarks. You only have to find it
once...

				Ned

Date: Tue, 20 Jul 2004 06:42:22 -0700
From: Lyndon Nerenberg <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
cc: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: RE: Has IANA gone mad?
Sender: [email-masked]

--On 2004-7-20 8:32 AM -0400 Scott Hollenbeck <[email-masked]> 
wrote:

> Among any of those umpteen times, did you happen to mention the
> situation to the IETF Secretariat?  If brought to their attention I'm
> sure they'd be willing to put a link to the tracker in an obvious
> place.

Yes (via the AD (Ned), and to the RFC Editor). (And I suspect via 
ietf@, although it has been long enough that I no longer remember.)

--lyndon

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lyndon Nerenberg'" <[email-masked]>
Cc: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: RE: Has IANA gone mad?
Date: Tue, 20 Jul 2004 08:32:27 -0400
Importance: Normal
Sender: [email-masked]

> And I note in passing, for the UMPTEENTH time, that the bloody 
> datatracker is buried in such a non-obvious place that 
> expecting anyone 
> to use it is pointless. (Use it? How on earth do you expect anyone to 
> even FIND it?)
> 
> Either put the bloody thing UP FRONT ON THE RFC AND ID pages at 
> ietf.org, or burn it.

Among any of those umpteen times, did you happen to mention the situation to
the IETF Secretariat?  If brought to their attention I'm sure they'd be
willing to put a link to the tracker in an obvious place.

I'll send a request myself momentarily.

-Scott-

Date: Tue, 20 Jul 2004 05:01:15 -0700
From: Lyndon Nerenberg <[email-masked]>
To: [email-masked], Bruce Lilly <[email-masked]>
cc: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

--On 2004-7-19 11:23 PM -0700 [email-masked] wrote:

> I note in passing that it is easy to determine the status of any
> draft; this is what the datatracker is for.

And I note in passing, for the UMPTEENTH time, that the bloody 
datatracker is buried in such a non-obvious place that expecting anyone 
to use it is pointless. (Use it? How on earth do you expect anyone to 
even FIND it?)

Either put the bloody thing UP FRONT ON THE RFC AND ID pages at 
ietf.org, or burn it.

--lyndon

Date: Mon, 19 Jul 2004 23:23:02 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Bruce Lilly <[email-masked]>
Cc: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

> > I think you worry too much. The fact of the matter is that people, including
> > quite a few major vendors, implement internet-drafts all the time. Heck, they
> > even implement _unapproved_ internet-drafts all the time. (IMO sometimes this
> > is justified but often it isn't.) But AFAIK there have been no sightings of the
> > protocol police swooping down and making arrests.

> Sure, there's no enforcement -- but I still want to do the right thing w.r.t.
> not citing drafts as references.

If you really believe this you're completely missing the point of the IETF
process. There are drafts and then there are drafts. Referencing a random draft
that Joe Blow put out there is one thing, referencing a draft that has been
approved for publication as an RFC is quite another. An approved draft in
effect _is_ a standard; it just hasn't completed the publication process yet.

I note in passing that it is easy to determine the status of any draft;
this is what the datatracker is for.

Now, you may argue that there's some chance that a document may change or even
be withdrawn between the time it is approved and the time it comes out as an
RFC. But the validity of this concern doesn't stand up when you examine the
publication record -- there have only been a couple of times this sort of thing
has happened. There have been many more cases where something that was approved
as proposed standard was substantially changed when the document was revised
and republished, so if you're going to get tense about stuff changing on you,
you'd best not touch anything that hasn't made it to standard status.

> My case is perhaps a bit unusual (the
> implementation is a validating parser, which can emit a message including
> references when there's a standards violation or potential interoperability
> issue).

I see nothing unusual about it, nor do I see any problem with such an
implementation being based on an approved draft.

> > It creates a situation where additional steps are necessary. IANA has more than
> > enough to do as it is, and experience has shown that adding considerable
> > coordination overhead just to achieve an _extremely_ slight increase in
> > coherency is almost never a good idea.

> It seems to me that having IANA update the registry *twice* (once with the media
> type and a bogus pointer to a non-RFC, and then again when the RFC is published)
> would be more work than updating it *once*.

Performing several separate actions that require no special coordination is
much, much easier than performing even one action that would have to be tightly
coordinated.

>  Alternatively, since the registry
> is in HTML format, the incomplete information could be commented out until RFC
> publication; if I recall correctly, it's not at all difficult to do in Adobe
> PageMill 3.0 (which is apparently what IANA uses).

Sorry. The goal here is to get things checked, checked, and rechecked; a
commented out registration entry isn't readily visible for authors to check and
approve. So, while this might be easy for IANA to do, doing so breaks a much
more important aspect of the process.
 
> The msgtrk issue isn't the first or only (or even the worst) problem; sometime
> last November, IANA also introduced message/CPIM, and after 8 months or so, there
> still isn't any RFC reference -- and the draft had already passed its expiration
> date by last November (the cpim draft expired about a year ago, in July 2003).

First, draft-ietf-impp-cpim-msgfmt-08.txt was approved as a proposed standard
back in October, 2003. (I again note that you could have determined this by
checking the datatracker.) Drafts approved for publication do not expire; the
notion that this registration was based on a draft that has now expired is
totally  bogus.

Second, this document is currently in 48 hour author review (a fact you could
have easily determined by checking the RFC Editor queue), so its publication is
imminent.

> Now I'm not sure exactly what you meant earlier by "The actual RFC then gets
> published in fairly short order after IANA actions are completed", but I think
> we probably have a different idea of what constitutes "fairly short order".

The editing process for most documents is pretty quick. However, there are
sometimes exceptions - a document will have some issue or other that prevents
its publication as an RFC from occurring in a timely fashion.

If memory serves, draft-ietf-impp-cpim-msgfmt-08.txt was delayed due to
some normative references not being available. This sort of thing
happens from time to time.

> I don't want to belabor the point; message/CPIM with no RFC was an annoyance, but
> was until recently the only unresolved entry in the message media type registry.
> With the addition of message/tracking-status -- with message/CPIM still unresolved --
> I hope I'm not seeing the continuation of a trend.

If the trend you refer to is the immediate appearance of IANA registrations of
stuff that appears in approved drafts, it is a trend I for one would love to
see continue, regardless of the time it takes for the drafts the registry
refers to to complete the publication process.

				Ned

Date: Mon, 19 Jul 2004 19:49:17 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
CC: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

[email-masked] wrote:

> I think you worry too much. The fact of the matter is that people, including
> quite a few major vendors, implement internet-drafts all the time. Heck, they
> even implement _unapproved_ internet-drafts all the time. (IMO sometimes this
> is justified but often it isn't.) But AFAIK there have been no sightings of the
> protocol police swooping down and making arrests.

Sure, there's no enforcement -- but I still want to do the right thing w.r.t.
not citing drafts as references.  My case is perhaps a bit unusual (the
implementation is a validating parser, which can emit a message including
references when there's a standards violation or potential interoperability
issue).

>>>>Ideally the RFC and IANA registration
>>>>would happen simultaneously; RFC first seems workable, but registration w/o
>>>>RFC causes difficulties.
>>>
>>>
>>>Ideally, perhaps, but it isn't practical.
> 
> 
>>In principle, it doesn't seem to me to be a big deal to withhold publication
>>(review is a separate issue) in the registry until the RFC is published...
> 
> 
> It creates a situation where additional steps are necessary. IANA has more than
> enough to do as it is, and experience has shown that adding considerable
> coordination overhead just to achieve an _extremely_ slight increase in
> coherency is almost never a good idea.

It seems to me that having IANA update the registry *twice* (once with the media
type and a bogus pointer to a non-RFC, and then again when the RFC is published)
would be more work than updating it *once*.  Alternatively, since the registry
is in HTML format, the incomplete information could be commented out until RFC
publication; if I recall correctly, it's not at all difficult to do in Adobe
PageMill 3.0 (which is apparently what IANA uses).

The msgtrk issue isn't the first or only (or even the worst) problem; sometime
last November, IANA also introduced message/CPIM, and after 8 months or so, there
still isn't any RFC reference -- and the draft had already passed its expiration
date by last November (the cpim draft expired about a year ago, in July 2003).
Now I'm not sure exactly what you meant earlier by "The actual RFC then gets
published in fairly short order after IANA actions are completed", but I think
we probably have a different idea of what constitutes "fairly short order".

I don't want to belabor the point; message/CPIM with no RFC was an annoyance, but
was until recently the only unresolved entry in the message media type registry.
With the addition of message/tracking-status -- with message/CPIM still unresolved --
I hope I'm not seeing the continuation of a trend.

From: "Charles Lindsey" <[email-masked]>
To: "ietf-822mailing list" <[email-masked]>
Subject: RE: Mandatory From field, anonymity, and hacks
Date: Mon, 19 Jul 2004 21:23:52 +0100
Importance: Normal
Sender: [email-masked]

>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Bruce Lilly
>Sent: 15 July 2004 15:16
>To: ietf-822mailing list
>Subject: Mandatory From field, anonymity, and hacks
>
>
>In some cases, a message author desires some degree of anonymity.  The
>requirement for a From field has led to the use of some hacks in order to
>comply with the letter of RFC 2822 and its predecessors, while
>providing some
>degree of anonymity and rendering the From field unusable for
>manual replies.
>For example, RFC 3261 section 23.4.3 and RFC 3323 section
>4.1.1.3 recommend
>use of the reserved DNS ".invalid" domain (RFC 2606) to provide
>some degree
>of anonymity.  There are some Internet drafts which do likewise.
> I believe
>such use goes somewhat beyond the intent of RFC 2606 in
>reserving names for
>test and example purposes.

Yes, we had long discussions about this in the USEFOR WG. The feeling was
that 'munging' addresses for spam avoidance was a Bad Thing, and that the
only socially acceptable thing was to use your genuine email address. But
we had to face the fact that people were going to do it anyway. OTOH, we
could not openly condone or deprecate the practice in a standards track
document.

What we did, therefore, was to use wording, essentially the same as RFC
2822, that the From address should be the email address of the
author/poster. But we then added that if the poster should "for whatever
reasons" wish to use a non-working email address, then he SHOULD use a
domain ending in ".invalid".
>
>Making the From header field optional would eliminate the need
>for such hacks
>by persons who desire the degree of anonymity that such hacks
>provide; those
>persons could simply avoid including a From field at all, rather than
>including a hacked bogus address in a From field.

But that does not really solve the problem. People still want to identify
themselves (and their readers certainly want to know who is writing to
them, whether in News or Email). So at least you need the <phrase> with
the Real Name (which might actually be a pseudonym), and the From field is
the proper place for that. One might argue that the <address> part of the
header could be omitted, but I think I would prefer to make people use
something ugly like the ".invalid" thing just to prevent it from becoming
a thing that everybody did as a matter of course (at which point the
spammers would simply move to some other method of garnering addresses).

Charles.

Date: Mon, 19 Jul 2004 12:27:33 -0700 (PDT)
From: [email-masked]
Subject: Re: Suggestion : New Content-Disposition parameters...
To: Russ Allbery <[email-masked]>
Cc: ietf-822imcorg <[email-masked]>
Sender: [email-masked]

> Arnt Gulbrandsen <[email-masked]> writes:

> > Is there a single (or a very few) interoperably used fields, in
> > practice? I've heard of X-No-Archive and Archive - who supports those
> > two?

> Archive is very sparsely used, and I'm not sure if it's really used by
> anyone in an interoperable fashion.  X-No-Archive is widely respected by a
> variety of software, most notably Google Groups.

> It should be considered purely a request, IMO, since the definition of
> archive is iffy and it's hard to really formalize policy without getting
> into very complex rules engines.

Agreed. Among other things, there are going to be cases where every message
sent to a given destination need to be archived for legal purposes.

> Note that X-No-Archive applies to the entire message.  The implications of
> a Content-Disposition parameter that could be applied to arbitrarily
> nested parts of a complex MIME message and not visible in the top-level
> headers for an implementor trying to honor it are a bit troubling to me.
> Without it being trivial to determine the archivability of a message, I
> expect many archives wouldn't bother.

Excellent point. A per-message archive: yes/no sort of field is something that
can be implemented with minimal fuss in many cases and makes considerable sense
as a suggestion to archival agents. Per-part archive suggestions, OTOH, are
going to be a royal pain to implement: Consider the implications of marking all
parts of a multipart as do-not-archive (do you then remove the multipart
entirely?), the implications of marking one part that happens to be essential
in a multipart/related (might as well drop the whole thing, but how do you know
that?), what to do when a part of a signed message is removed, and so on. I
certainly wouldn't bother to implement this mess.

I will also point out that archiving is really an operation done in parallel to
normal message processing. As such, it really doesn't make sense for it to be a
content-disposition paramater, as it has nothing to do with the "normal"
message disposition process.

				Ned

Date: Mon, 19 Jul 2004 14:58:01 -0400
From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Email archiving (was: New Content-Disposition...)
Sender: [email-masked]

> The W3C email system creates public archives of many of its mailing 
> lists.  Before accepting a message for a mailing list, the system attempts 
> to ensure that the sender has given permission for such publication - when 
> email is received from a source for which such permission is not "on 
> record", a response is sent asking for such permission.
> 
> This suggests to me a possibility of turning around the idea to indicate 
> *permission* to for long-term archival storage. 

In the context of interpersonal email, this seems a bit silly.  Do you 
need "permission" to save this message from me in your message store for 
as long as you wish?

Date: Mon, 19 Jul 2004 14:53:12 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

> 
> Keith Moore writes:
> > seems reasonable at least from a theoretical perspective.  from a 
> > practical perspective, I wonder if it's at all realistic to request 
> > that email not be archived, or that some part of a message not be 
> > archived.
> 
> A good question, but I think it's beside the point. If the existing 
> non-standard field is reasonably widely used, both by message writers 
> and archivers, isn't that in itself reason enough to standadize it?

To answer your question, no.  Just because a field is widely used does
not mean that it meets the criteria for standardization. 

Date: Mon, 19 Jul 2004 09:11:20 +0100
To: Keith Moore <[email-masked]>, ietf-822imcorg <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Email archiving (was: New Content-Disposition...)
Sender: [email-masked]

At 14:25 18/07/04 -0400, Keith Moore wrote:
>>The above and Keith's comments w.r.t. copyright notwithstanding, what about
>>some indication by the author to indicate a preference against long-term
>>archiving of the media content?
>
>seems reasonable at least from a theoretical perspective.  from a 
>practical perspective, I wonder if it's at all realistic to request that 
>email not be archived, or that some part of a message not be archived.

By way of a datum, and a little thinking "aloud"...

The W3C email system creates public archives of many of its mailing 
lists.  Before accepting a message for a mailing list, the system attempts 
to ensure that the sender has given permission for such publication - when 
email is received from a source for which such permission is not "on 
record", a response is sent asking for such permission.

This suggests to me a possibility of turning around the idea to indicate 
*permission* to for long-term archival storage.  That said, I'm not sure if 
it would be used much in practice (unless, maybe, configured in an MUA 
address book such that the poermission is added to messages sent to known 
public mailing lists?)

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: "Scott Hollenbeck" <[email-masked]>
To: "'ietf-822 mailing list'" <[email-masked]>, <[email-masked]>
Cc: "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: RE: Has IANA gone mad?
Date: Sun, 18 Jul 2004 19:33:47 -0400
Sender: [email-masked]

> Is the registration template in the draft of a document 
> intended to become a Proposed Standard not reviewed by the 
> IESG?  Doesn't registration in the IETF tree require IESG 
> review and publication as an RFC [RFC 2048 section 2.1.1]?
> What about RFC 2048 [2.3.1] -- was this proposed registration 
> posted to the ietf-types mailing list for review (I looked at 
> the mailing list archives, but couldn't find anything in the 
> past 4 months-- but there seems to be an awful lot of spam)?

Ned was the shepherding AD before I completed the IESG actions on this
document.  He knows the history better than I do, but I can confirm (as I
said in my original reply) that this document _was_ reviewed and approved by
the IESG.  It _will_ become an RFC.  You can check the status, including all
of the relevant IESG comments and dates, using the I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi

-Scott-

Date: Sun, 18 Jul 2004 15:38:50 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Bruce Lilly <[email-masked]>
Cc: [email-masked], "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Sender: [email-masked]

> > Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor
> > already work together closely to coordinate this sort of thing. Specifically,
> > the editing process has a phase during which the relevant registrations are
> > completed. The actual RFC then gets published in fairly short order
> > after IANA actions are completed.

> > The notion that having dangling reference in the registry for the very short
> > period of time while the publication process is completely is a problem does
> > not pass the laugh test. I doubt very much that implemetors are going to to
> > waste time prowling the registries looking for MIME types to support, and even
> > if some people have taken sufficient leave of their senses to do this sort of
> > thing it is not a practice we should condone.

> I guess we're going to have to agree to disagree about this. I do pay attention
> to the IANA registries, and I have implemented message/tracking-status including
> provision for 2.1.9 extended status, the extended action keywords, and the
> relevant REQUIRED, MUST, and MUST NOT provisions.  But I am at a loss to provide
> a reference justifying doing so.  Since the implementation is open source and
> is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but
> there is still the "Under no circumstances" clause that is troubling.

I think you worry too much. The fact of the matter is that people, including
quite a few major vendors, implement internet-drafts all the time. Heck, they
even implement _unapproved_ internet-drafts all the time. (IMO sometimes this
is justified but often it isn't.) But AFAIK there have been no sightings of the
protocol police swooping down and making arrests.

> > I'm afraid you're dead wrong about this. The reality is that registration
> > problems often don't turn up until the registration has been completed and
> > reviewed as part of the publication process. Failure to perform these action
> > prior to publication can and does lead to errors that have required
> > republication in the past.

> Is the registration template in the draft of a document intended to become a
> Proposed Standard not reviewed by the IESG?

Of course it is. But if review were the same as actually performing an action,
we  wouldn't have implementation requirements for progression along the
standards track. The fact of the matter is that there can be problems that
aren't apparent at the review stage and which only turn up during the
registration process.

  Doesn't registration in the IETF
> tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?

Of course it does. But again, review != actually performing an action.

> What about RFC 2048 [2.3.1] -- was this proposed registration posted to the
> ietf-types mailing list for review (I looked at the mailing list archives, but
> couldn't find anything in the past 4 months-- but there seems to be an awful
> lot of spam)?

I doubt it, but this step is optional in any case.

> >>Ideally the RFC and IANA registration
> >>would happen simultaneously; RFC first seems workable, but registration w/o
> >>RFC causes difficulties.
> >
> >
> > Ideally, perhaps, but it isn't practical.

> In principle, it doesn't seem to me to be a big deal to withhold publication
> (review is a separate issue) in the registry until the RFC is published...

It creates a situation where additional steps are necessary. IANA has more than
enough to do as it is, and experience has shown that adding considerable
coordination overhead just to achieve an _extremely_ slight increase in
coherency is almost never a good idea.

Even granting that such coordination wouldn't cause more problems than it 
solves, you're letting the costly best be the enemy of the much cheaper plenty
good enough.

> > > So presumably comments such as the "xtext" issue would have to be directed to
> > > the RFC editor/authors once the RFC is published.

> > The RFC Editor routinely checks for references to documents that have been
> > obsoleted. So this is almost certainly going to be caught by the editing
> > process. Of course you can always drop the RFC Editor or the authors a note to
> > make sure it gets dealt with.

> In this case it seems that the specific issue mentioned arises because text
> from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated.
> It's not a case of "cite by reference", which might have avoided the issue,
> but of copying of text.

Again, means exist to correct this sort of thing as part of the editing
process.

				Ned

Date: Sun, 18 Jul 2004 17:40:34 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: "'ietf-822 mailing list'" <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
CC: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

[email-masked] wrote:

> Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor
> already work together closely to coordinate this sort of thing. Specifically,
> the editing process has a phase during which the relevant registrations are
> completed. The actual RFC then gets published in fairly short order
> after IANA actions are completed.
> 
> The notion that having dangling reference in the registry for the very short
> period of time while the publication process is completely is a problem does
> not pass the laugh test. I doubt very much that implemetors are going to to
> waste time prowling the registries looking for MIME types to support, and even
> if some people have taken sufficient leave of their senses to do this sort of
> thing it is not a practice we should condone.

I guess we're going to have to agree to disagree about this. I do pay attention
to the IANA registries, and I have implemented message/tracking-status including
provision for 2.1.9 extended status, the extended action keywords, and the
relevant REQUIRED, MUST, and MUST NOT provisions.  But I am at a loss to provide
a reference justifying doing so.  Since the implementation is open source and
is not sold, I suppose I could weasel out of the RFC 2026 "vendor" clause, but
there is still the "Under no circumstances" clause that is troubling.

> I'm afraid you're dead wrong about this. The reality is that registration
> problems often don't turn up until the registration has been completed and
> reviewed as part of the publication process. Failure to perform these action
> prior to publication can and does lead to errors that have required
> republication in the past.

Is the registration template in the draft of a document intended to become a
Proposed Standard not reviewed by the IESG?  Doesn't registration in the IETF
tree require IESG review and publication as an RFC [RFC 2048 section 2.1.1]?
What about RFC 2048 [2.3.1] -- was this proposed registration posted to the
ietf-types mailing list for review (I looked at the mailing list archives, but
couldn't find anything in the past 4 months-- but there seems to be an awful
lot of spam)?

>>Ideally the RFC and IANA registration
>>would happen simultaneously; RFC first seems workable, but registration w/o
>>RFC causes difficulties.
> 
> 
> Ideally, perhaps, but it isn't practical.

In principle, it doesn't seem to me to be a big deal to withhold publication
(review is a separate issue) in the registry until the RFC is published...

>>So presumably comments such as the "xtext" issue would have to be directed to
>>the RFC editor/authors once the RFC is published.
> 
> 
> The RFC Editor routinely checks for references to documents that have been
> obsoleted. So this is almost certainly going to be caught by the editing
> process. Of course you can always drop the RFC Editor or the authors a note to
> make sure it gets dealt with.

In this case it seems that the specific issue mentioned arises because text
from RFC 1894 was cloned, and when 1894 was obsoleted, it wasn't updated.
It's not a case of "cite by reference", which might have avoided the issue,
but of copying of text.

Date: Sun, 18 Jul 2004 13:25:34 -0700 (PDT)
From: [email-masked]
Subject: Re: Has IANA gone mad?
To: Bruce Lilly <[email-masked]>
Cc: Scott Hollenbeck <[email-masked]>, "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Sender: [email-masked]

> Scott Hollenbeck wrote:
> > IANA made the assignment because this document:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt
> >
> > was approved for publication as a Proposed Standard by the IESG on
> > 2004-03-23 and the document is now in the RFC Editor's queue.  The IANA
> > actions have to be completed before the document can be finished by the RFC
> > Editor.

> While I can understand the rationale, it does pose some difficulties for
> implementors; lacking an RFC, implementors are at somewhat of a loss to
> provide justification for handling the MUST, MUST NOT, REQUIRED, etc.
> provisions of the applicable specification ("Under no circumstances
> should an Internet-Draft be referenced [...[ nor should a vendor claim
> compliance with an Internet-Draft" -- RFC 2026).  Some coordination
> between the rfc-editor and IANA would be helpful to implementors.

Bruce, I'm sorry, but this is simply absurd. The IANA and the RFC Editor
already work together closely to coordinate this sort of thing. Specifically,
the editing process has a phase during which the relevant registrations are
completed. The actual RFC then gets published in fairly short order
after IANA actions are completed.

The notion that having dangling reference in the registry for the very short
period of time while the publication process is completely is a problem does
not pass the laugh test. I doubt very much that implemetors are going to to
waste time prowling the registries looking for MIME types to support, and even
if some people have taken sufficient leave of their senses to do this sort of
thing it is not a practice we should condone.

> Having
> the RFC first (which includes the registration template information for
> the relevant media type) would not be a problem, as I see it.

I'm afraid you're dead wrong about this. The reality is that registration
problems often don't turn up until the registration has been completed and
reviewed as part of the publication process. Failure to perform these action
prior to publication can and does lead to errors that have required
republication in the past.

The approach that's currently used is both practical and has not produced the
many operational problems other approaches we've used in the past have had.

> whereas
> the current situation (registered media type with no document that can
> be referenced) does pose problems.

I disagree.

> Ideally the RFC and IANA registration
> would happen simultaneously; RFC first seems workable, but registration w/o
> RFC causes difficulties.

Ideally, perhaps, but it isn't practical.

> > The msgtrk working group will be closed once the remaining documents (all of
> > which are in the RFC Editor's queue) are published as RFCs.

> It's a shame that the draft in question (16 months old) has a number of
> oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464
> (e.g. reference to "xtext", which would by analogy be equivalent to me
> pointing out that dictionaries provide a definition of the word "rhinoceros",
> which is otherwise not used anywhere in this message).

> So presumably comments such as the "xtext" issue would have to be directed to
> the RFC editor/authors once the RFC is published.

The RFC Editor routinely checks for references to documents that have been
obsoleted. So this is almost certainly going to be caught by the editing
process. Of course you can always drop the RFC Editor or the authors a note to
make sure it gets dealt with.

				Ned

To: ietf-822imcorg <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 18 Jul 2004 13:35:52 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:

> Is there a single (or a very few) interoperably used fields, in
> practice? I've heard of X-No-Archive and Archive - who supports those
> two?

Archive is very sparsely used, and I'm not sure if it's really used by
anyone in an interoperable fashion.  X-No-Archive is widely respected by a
variety of software, most notably Google Groups.

It should be considered purely a request, IMO, since the definition of
archive is iffy and it's hard to really formalize policy without getting
into very complex rules engines.

Note that X-No-Archive applies to the entire message.  The implications of
a Content-Disposition parameter that could be applied to arbitrarily
nested parts of a complex MIME message and not visible in the top-level
headers for an implementor trying to honor it are a bit troubling to me.
Without it being trivial to determine the archivability of a message, I
expect many archives wouldn't bother.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 18 Jul 2004 16:13:37 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: "'ietf-822 mailing list'" <[email-masked]>
Organization: Bruce Lilly
To: Scott Hollenbeck <[email-masked]>
CC: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

Scott Hollenbeck wrote:
> IANA made the assignment because this document:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt
> 
> was approved for publication as a Proposed Standard by the IESG on
> 2004-03-23 and the document is now in the RFC Editor's queue.  The IANA
> actions have to be completed before the document can be finished by the RFC
> Editor.

While I can understand the rationale, it does pose some difficulties for
implementors; lacking an RFC, implementors are at somewhat of a loss to
provide justification for handling the MUST, MUST NOT, REQUIRED, etc.
provisions of the applicable specification ("Under no circumstances
should an Internet-Draft be referenced [...[ nor should a vendor claim
compliance with an Internet-Draft" -- RFC 2026).  Some coordination
between the rfc-editor and IANA would be helpful to implementors. Having
the RFC first (which includes the registration template information for
the relevant media type) would not be a problem, as I see it. whereas
the current situation (registered media type with no document that can
be referenced) does pose problems.  Ideally the RFC and IANA registration
would happen simultaneously; RFC first seems workable, but registration w/o
RFC causes difficulties.

> The msgtrk working group will be closed once the remaining documents (all of
> which are in the RFC Editor's queue) are published as RFCs.

It's a shame that the draft in question (16 months old) has a number of
oddities -- being based on RFC 1894 -- which have been corrected in RFC 3464
(e.g. reference to "xtext", which would by analogy be equivalent to me
pointing out that dictionaries provide a definition of the word "rhinoceros",
which is otherwise not used anywhere in this message).

So presumably comments such as the "xtext" issue would have to be directed to
the RFC editor/authors once the RFC is published.

Date: Sun, 18 Jul 2004 15:48:50 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg <[email-masked]>
Organization: Bruce Lilly
To: Arnt Gulbrandsen <[email-masked]>
CC: ietf-822imcorg <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Keith Moore writes:
> 
>> seems reasonable at least from a theoretical perspective.  from a
>> practical perspective, I wonder if it's at all realistic to request
>> that email not be archived, or that some part of a message not be
>> archived.
> 
> 
> A good question, but I think it's beside the point. If the existing
> non-standard field is reasonably widely used, both by message writers
> and archivers, isn't that in itself reason enough to standadize it?
> 
> Is there a single (or a very few) interoperably used fields, in
> practice? I've heard of X-No-Archive and Archive - who supports those two?

Archive seems to have some existing defacto support within Usenet.  HTTP has
similar considerations, addressed by the standardized Cache-Control [HTTP,
RFC 2616, section 14.9] header field, which has all sorts of bells and
whistles.

The usefor working group is discussing possible standardization of the Archive
field.  There are a few issues:

1. uses other than Usenet should probably be considered; a general solution
   that encompasses Usenet-specific needs and similar needs of other applications
   of RFC [2]822 Internet Message Format is probably superior to an application-
   specific field.

2. There has been a proposal to use RFC 2231 (MIME Content-Type/Content-Disposition)
   parameters with Archive.   That would be a precedent (use of RFC 2231
   parameters with non-MIME fields).  [Although that's been discussed w.r.t.
   Keith's Auto-Submitted field draft -- mea culpa]

3. Message parts vs. the message as a whole.  Clearly Content-Disposition can
   apply in either case (as detailed in RFC 2183 w.r.t. composite media types).
   While non-MIME fields could be included in MIME-part headers, there is no
   reason to expect that they would be interpreted appropriately there.

4. HTTP's Cache-Control might subsume the unofficial Archive and RFC 1036 [2.2.4]
   Expires fields.  Cache-Control has a plethora of options (w/o the complexity
   of RFC 2231 parsing). But I'm not sure that the name is sufficiently generic for
   general RFC [2]822 use, and as it is not a MIME field, it lacks some of the
   potential flexibility of a Content-Disposition parameter.

As there has been some recent discussion here w.r.t. Content-Disposition parameters,
I thought I'd run the concept of an archive/no-archive parameter to the
Content-Disposition field up the flagpole here to see how much resistance there
might be.

Date: Mon, 19 Jul 2004 00:27:31 +0530
From: Arnt Gulbrandsen <[email-masked]>
To: ietf-822imcorg <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

Keith Moore writes:
> seems reasonable at least from a theoretical perspective.  from a 
> practical perspective, I wonder if it's at all realistic to request 
> that email not be archived, or that some part of a message not be 
> archived.

A good question, but I think it's beside the point. If the existing 
non-standard field is reasonably widely used, both by message writers 
and archivers, isn't that in itself reason enough to standadize it?

Is there a single (or a very few) interoperably used fields, in 
practice? I've heard of X-No-Archive and Archive - who supports those 
two?

Arnt

Cc: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Date: Sun, 18 Jul 2004 14:25:53 -0400
To: ietf-822imcorg <[email-masked]>
Sender: [email-masked]

>> Quite right. Content disposition paramaters are supposed to carry 
>> generally
>> meaningful information that may be needed to act on the associated
>> disposition.
>> So we have filename, creation date, and modification date parameters,
>> which are
>> all useful when putting message content in  a file, which is what the
>> attachment disposition often ends up doing.
>>
>> Creator/author identity only kinda sorta falls into this category; IMO
>> version and copyright information miss it by a mile.
>
> The above and Keith's comments w.r.t. copyright notwithstanding, what 
> about
> some indication by the author to indicate a preference against 
> long-term
> archiving of the media content?

seems reasonable at least from a theoretical perspective.  from a 
practical perspective, I wonder if it's at all realistic to request 
that email not be archived, or that some part of a message not be 
archived.

Date: Sat, 17 Jul 2004 21:54:04 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: ietf-msgtrk mailing list <[email-masked]>, [email-masked]
Subject: Re: Has IANA gone mad?
Sender: [email-masked]

RFC-ietf-msgtrk-trkstat-05.txt is IANA's shorthand for a document that is in the 
RFC Editor's queue, based on the internet-draft of the given name.

Yes, ietf-msgtrk-trkstat-05.txt is more than six months old. When documents go 
into the IESG queue, and then the RFC Editor's queue, the six month rule no 
longer applies.

This document is one of a suite of documents about message tracking that will 
all be published together as a series of RFCs.

Most of the work in the message tracking working group was finished well over a 
year ago. Unfortunately, there were a few comments that came back from the IESG 
that caused a couple of cycles on a couple of the documents in the message 
tracking suite. That held up the publication of all of the documents.

	Tony Hansen
	[email-masked]

Bruce Lilly wrote:

> Sent to ietf-822 and ietf-msgtrk mailing lists, cc to [email-masked], responses
> default to ietf-822
> 
> Yesterday, "message/tracking-status" appeared in the IANA registry for MIME
> message media types (http://www.iana.org/assignments/media-types/message/).
> It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference document -- of
> course there is no such document.  The closest existing document is a draft
> dated March 2003, more than a year old ("Internet drafts are valid for six
> months").
> 
> Why on Earth did this suddenly appear yesterday?
> 
> The ietf-msgtrk mailing list appears to be dormant; in the last three months
> the only message to appear on that mailing list's archive are spam messages
> (http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  There are fewer
> than a dozen message in the mailing list archive in the past year, spam
> included.
> 
> What's going on?!?
> 

From: "Scott Hollenbeck" <[email-masked]>
To: "'ietf-822 mailing list'" <[email-masked]>, "'ietf-msgtrk mailing list'" <[email-masked]>
Subject: RE: Has IANA gone mad?
Date: Sat, 17 Jul 2004 17:55:09 -0400
Sender: [email-masked]

IANA made the assignment because this document:

http://www.ietf.org/internet-drafts/draft-ietf-msgtrk-trkstat-05.txt

was approved for publication as a Proposed Standard by the IESG on
2004-03-23 and the document is now in the RFC Editor's queue.  The IANA
actions have to be completed before the document can be finished by the RFC
Editor.

The msgtrk working group will be closed once the remaining documents (all of
which are in the RFC Editor's queue) are published as RFCs.

-Scott-
Area Advisor for MSGTRK

> -----Original Message-----
> From: Bruce Lilly [mailto:[email-masked]] 
> Sent: Saturday, July 17, 2004 3:43 PM
> To: ietf-msgtrk mailing list
> Subject: Has IANA gone mad?
> 
> 
> Sent to ietf-822 and ietf-msgtrk mailing lists, cc to 
> [email-masked], responses default to ietf-822
> 
> Yesterday, "message/tracking-status" appeared in the IANA 
> registry for MIME message media types 
> (http://www.iana.org/assignments/media-types/message/).
> It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference 
> document -- of course there is no such document.  The closest 
> existing document is a draft dated March 2003, more than a 
> year old ("Internet drafts are valid for six months").
> 
> Why on Earth did this suddenly appear yesterday?
> 
> The ietf-msgtrk mailing list appears to be dormant; in the 
> last three months the only message to appear on that mailing 
> list's archive are spam messages 
> (http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  
> There are fewer than a dozen message in the mailing list 
> archive in the past year, spam included.
> 
> What's going on?!?
> 
> 

Date: Sat, 17 Jul 2004 15:41:04 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822mailing list <[email-masked]>
Organization: Bruce Lilly
To: ietf-822mailing list <[email-masked]>
Subject: Re: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

One implication that I missed is w.r.t. the MIME media type message/rfc822,
which currently requires one of From, Subject, or Date fields in the media
header.  That might need to be reduced to one of Subject or Date.

Date: Sat, 17 Jul 2004 15:38:43 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822imcorg <[email-masked]>
Organization: Bruce Lilly
CC: ietf-822imcorg <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

[email-masked] wrote:

> Quite right. Content disposition paramaters are supposed to carry generally
> meaningful information that may be needed to act on the associated
> disposition.
> So we have filename, creation date, and modification date parameters,
> which are
> all useful when putting message content in  a file, which is what the
> attachment disposition often ends up doing.
> 
> Creator/author identity only kinda sorta falls into this category; IMO
> version and copyright information miss it by a mile. 

The above and Keith's comments w.r.t. copyright notwithstanding, what about
some indication by the author to indicate a preference against long-term
archiving of the media content?   That is distinct from copyright and from
the inherent ephemeral copying necessary for transport, but is meant to
address long-term archiving.  There is now in use an undocumented, unofficial
header field "Archive" used in Usenet messages for such an indication; might
that be suitable as a Content-Disposition parameter instead?

Date: Sat, 17 Jul 2004 15:28:56 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 mailing list <[email-masked]>
Organization: Bruce Lilly
To: ietf-msgtrk mailing list <[email-masked]>, ietf-822 mailing list <[email-masked]>
CC: [email-masked]
Subject: Has IANA gone mad?
Sender: [email-masked]

Sent to ietf-822 and ietf-msgtrk mailing lists, cc to [email-masked], responses
default to ietf-822

Yesterday, "message/tracking-status" appeared in the IANA registry for MIME
message media types (http://www.iana.org/assignments/media-types/message/).
It lists "RFC-ietf-msgtrk-trkstat-05.txt" as the reference document -- of
course there is no such document.  The closest existing document is a draft
dated March 2003, more than a year old ("Internet drafts are valid for six
months").

Why on Earth did this suddenly appear yesterday?

The ietf-msgtrk mailing list appears to be dormant; in the last three months
the only message to appear on that mailing list's archive are spam messages
(http://www.imc.org/ietf-msgtrk/mail-archive/maillist.html).  There are fewer
than a dozen message in the mailing list archive in the past year, spam
included.

What's going on?!?

Date: Fri, 16 Jul 2004 12:13:35 -0700 (PDT)
From: [email-masked]
Subject: Re: Suggestion : New Content-Disposition parameters...
To: Graham Klyne <[email-masked]>
Cc: Tanu Mutreja <[email-masked]>, ietf-822imcorg <[email-masked]>
Sender: [email-masked]

> At 20:21 06/07/04 +0530, Tanu Mutreja wrote:
> >I feel that few more parameters should / could also be added to the list
> >of content-disposition parameters. To be more precise, following
> >parameters related to the origin of a file should also be added i.e.
> >
> >1. Source of the file creation
> >2. Author of the file
> >3. A parameter to represent if the material is copyrighted or not?
> >4. Version of the file

> Notwithstanding the problematic issues noted elsewhere, I think it's also
> important to consider that Content-disposition is *not* a catch-all bucket
> for arbitrary message-content metadata (as Keith has also noted).

Quite right. Content disposition paramaters are supposed to carry generally
meaningful information that may be needed to act on the associated disposition.
So we have filename, creation date, and modification date parameters, which are
all useful when putting message content in  a file, which is what the
attachment disposition often ends up doing.

Creator/author identity only kinda sorta falls into this category; IMO 
version and copyright information miss it by a mile. Additionally,
I have difficulty imagining a useful matchup between what filesystems store
about file creators/authors and what you'd put in such a parameter.

> I think that alternative mechanisms that might be considered include:
> - new header fields

> - packaging the message with something like multipart/related and
> additional content containing a widely used metadata format (e.g. RDF)
> - linking the metadata to the content with something like a signature
> structure (e.g. along the lines of http://www.w3.org/TR/xmldsig-p3p-profile/)
> - incorporation into a Content-features header (RFC2912);  though this
> might be regarded as stretching this beyond its original intended purpose
> of conveying *media* features.

I don't think it is all that much of a stretch to call it a media feature.
As such, I'd say RFC 2912 would be the way to go for this, assuming it
makes sense at all (I remain to be convinced).

				Ned

Date: Thu, 15 Jul 2004 10:15:54 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822mailing list <[email-masked]>
Organization: Bruce Lilly
To: ietf-822mailing list <[email-masked]>
Subject: Mandatory From field, anonymity, and hacks
Sender: [email-masked]

RFC 2822 has relaxed some requirements which existed in RFC 822 w.r.t. mandatory
header fields (822 required at least one of To, Cc, Bcc; 2822 has no such
requirement).  However, both 822 and 2822 require a From header field.

Transport (IMAP, POP3, NNTP, SMTP, etc.) of messages does not make use of the
>From field.  The From field in an original message is not used in preparation
of MDNs (Disposition-Notification-To is used) or DSNs (envelope return address
is used).

In some cases, a message author desires some degree of anonymity.  The
requirement for a From field has led to the use of some hacks in order to
comply with the letter of RFC 2822 and its predecessors, while providing some
degree of anonymity and rendering the From field unusable for manual replies.
For example, RFC 3261 section 23.4.3 and RFC 3323 section 4.1.1.3 recommend
use of the reserved DNS ".invalid" domain (RFC 2606) to provide some degree
of anonymity.  There are some Internet drafts which do likewise.  I believe
such use goes somewhat beyond the intent of RFC 2606 in reserving names for
test and example purposes.

Making the From header field optional would eliminate the need for such hacks
by persons who desire the degree of anonymity that such hacks provide; those
persons could simply avoid including a From field at all, rather than
including a hacked bogus address in a From field.

The same considerations apply in the case of the Resent-From field.

Of course, in the absence of a From field, treatment of manual replies may
need to be worded slightly differently.  A Reply-To field, if present, would
be used whether or not a From field were present. It may also be worth
considering whether or not a Sender field should be required in the absence
of a From field.

Date: Wed, 07 Jul 2004 09:14:53 +0100
To: Tanu Mutreja <[email-masked]>, "[email-masked]" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

At 20:21 06/07/04 +0530, Tanu Mutreja wrote:
>I feel that few more parameters should / could also be added to the list 
>of content-disposition parameters. To be more precise, following 
>parameters related to the origin of a file should also be added i.e.
>
>1. Source of the file creation
>2. Author of the file
>3. A parameter to represent if the material is copyrighted or not?
>4. Version of the file

Notwithstanding the problematic issues noted elsewhere, I think it's also 
important to consider that Content-disposition is *not* a catch-all bucket 
for arbitrary message-content metadata (as Keith has also noted).

I think that alternative mechanisms that might be considered include:
- new header fields
- packaging the message with something like multipart/related and 
additional content containing a widely used metadata format (e.g. RDF)
- linking the metadata to the content with something like a signature 
structure (e.g. along the lines of http://www.w3.org/TR/xmldsig-p3p-profile/)
- incorporation into a Content-features header (RFC2912);  though this 
might be regarded as stretching this beyond its original intended purpose 
of conveying *media* features.

At this stage, you seem to be suggesting a solution without being clear how 
the information would be used -- is intended to be displayed to a message 
recipient, or consumed by a receiving application, or something else?  A 
clear statement of this requirement would, I think, make it easier to 
suggest appropriate ways of conveying the information.  Also:  how 
important is extensibility

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Cc: Keith Moore <[email-masked]>, Tanu Mutreja <[email-masked]>, [email-masked], [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: Suggestion : New Content-Disposition parameters...
Date: Tue, 6 Jul 2004 23:44:57 -0400
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

> In addition, I would point out that the first three items are already 
> handled
> within the content for some media types (e.g. application/pdf). In 
> such cases,
> inclusion of the same type of information outside of the content can 
> lead to
> one of the following problems (or a combination of the two):
>
> 1. the information is redundant, and therefore wastes some bandwidth
> 2. the information does not match that within the content, leading to
>    ambiguity

this brings up (for me) the question of where the information about 
copyright is obtained in the first place.  body part fields are 
supplied by the sender (or his UA) but the sender might not be the 
copyright holder of the attachment.  should the recipient trust the 
sender's assertion about such rights?  the sender could easily get it 
wrong.

Date: Tue, 06 Jul 2004 19:03:12 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Organization: Bruce Lilly
To: Tanu Mutreja <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

Tanu Mutreja wrote:

> I feel that few more parameters should / could also be added to the list
> of content-disposition parameters. To be more precise, following
> parameters related to the origin of a file should also be added i.e.
> 
> 1. Source of the file creation
> 2. Author of the file
> 3. A parameter to represent if the material is copyrighted or not?
> 4. Version of the file

I agree with Keith's remarks posted to ietf-822.

In addition, I would point out that the first three items are already handled
within the content for some media types (e.g. application/pdf). In such cases,
inclusion of the same type of information outside of the content can lead to
one of the following problems (or a combination of the two):

1. the information is redundant, and therefore wastes some bandwidth
2. the information does not match that within the content, leading to
   ambiguity

In cases where the content has no such provision, such information could be
provided textually by wrapping it in a multipart/mixed wrapper with the
actual content.  The information could even be given a different disposition
than the content, e.g. it could be marked for inline presentation, while the
content could be marked as "attachment".  Unfortunately, some UAs don't
handle nested MIME parts well more than a decade after MIME's introduction,
but that's another matter.

Regarding the 4th item, it's not clear whether that is meant to indicate the
version of the content (as in today's revision of the "foo" document) or the
version of the application required to read the content (as in the version of
Microsoft PowerPoint needed to read a given piece of content of media type
application/vnd.ms-powerpoint [files generated by version 4 of MS PowerPoint
cannot be read with version 3 or earlier programs]).  The former case could
be indicated via a Content-Description field, and the latter would probably
best be handled via a media/subtype-specific parameter to the Content-Type
field, as it is an attribute of the media type rather than its disposition.
Ideally, the registrant of a media type which is anticipated to have version
issues that result in a loss of backward compatibility would make provision
for a parameter to indicate the format version (vnd.ms-powerpoint does not
do so, incidentally).

Date: Tue, 6 Jul 2004 15:11:46 -0400
From: Keith Moore <[email-masked]>
To: Tanu Mutreja <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Suggestion : New Content-Disposition parameters...
Sender: [email-masked]

I have two kinds of reservations about this:

1. indicating any copyright information in the headers of a body part
2. using content-disposition for this purpose

Copyright is by itself a problematic issue.  Many  people (including
myself) believing that traditional notions of copyright are obsolete and
harmful when applied to the networked world.

It's not immediately clear how the information would be used  by the
recipient.  In countries that have signed the Berne convention, 
essentially everything is copyrighted anyway.  And yet the very actions
of transmitting a message over email, reading the message from a message
store using POP or IMAP, and using attachments (e.g. providing a copy of
"just the attachment" in a file where it can be used by a  helper
application) requires making several copies of the message.  
Furthermore, to be effective any kind of limitation on the use of the
attachment would need to be communicated to any helper application (so
that, for instance, "save" or "print" functions could be disabled or
limited).  In this context it seems clear that (if the sender has the
right to do so) some permission to copy is being granted by the
sender to the recipient and to various intermediaries, or (if the
sender does not have that right) that the sender is violating one or
more rights held by the content owner.

Also, copyright laws are particular about what kinds of marks are 
suitable for legally serving as copyright notice, and it's not clear 
that a new content-disposition field, or a new body-part header field, 
would meet the requirements of such laws - particularly when the notice 
would in some sense be separated from the actual copyrighted work.

So I believe that copyright notices in the message header would be at
best ambigious and ineffective, and at worst confusing and detrimental.

Whether to use the Content-Disposition field for this purpose is a
separate issue.  Content-Disposition is intended to be used by the
sender to make  recommendations as to how the recipient (or the
recipient's mail user  agent) should deal with the document.  It's not
clear that copyright information falls into that category, because
the very notion of copyright is ambiguous in an environment where there
is no obvious distinction between copying and ordinary use. 

The entire body-part header (rather than one particular field) exists to
describe the body-part, and the purist in me would like to  keep each
field of that header (includingcontent-disposition) true to its purpose,
so that there is a clean separation of function between the different
fields.  For instance, it might be found desirable to display copyright
information to the recipient (so that he or she can be expected to act
in awareness of that notice).  But content-disposition fields are not
normally displayed.

So _if_ it were found to be desirable to include copyright information
in the MIME body part header, I believe it should be in a separate field
than Content-Disposition.

Keith

--
Regime change 2004 - better late than never.

Date: Tue, 06 Jul 2004 20:21:27 +0530
From: Tanu Mutreja <[email-masked]>
Subject: Suggestion : New Content-Disposition parameters...
To: "[email-masked]" <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Hi Everybody,

Further to the document posted at 
http://xml.resource.org/public/rfc/html/rfc2183.html , I would like to 
suggest adding few more content-disposition parameters. I would be 
grateful if you could please spend some time on reading this mail and 
provide your valuable inputs.

I feel that few more parameters should / could also be added to the list 
of content-disposition parameters. To be more precise, following 
parameters related to the origin of a file should also be added i.e.

 1. Source of the file creation
 2. Author of the file
 3. A parameter to represent if the material is copyrighted or not?
 4. Version of the file

Since the very basic nature of email involves extremely wide 
transmission of content, maintaining information like the above becomes 
quite useful. It can help retaining & tracking down basic history and 
information of the original content flowing throughout the email 
messages. Even though it's just a recommendation and the recipient is 
free to comply or not to comply, it can definitely help the sender 
guarding content to some extent.

To add further, my feeling behind the suggestion is that 
"content-disposition" header is intended to provide the sender a way to 
make his / her recommendations to the recipient about the MIME entities. 
Some of the MIME entities carry a set of properties like above. 
Providing these properties as part of Content-Disposition header gives a 
chance to sender to emphasize about the existence of these properties. 
Then it's up to the recipient / MUA how to deal with it.

Additionally, most of the email users are normal users who are not very 
familiar with the technical concepts involved inside. For various 
reasons these users, when email receivers, may generally be willing to 
accept the MUA / email-client action taken for those recommendations 
e.g. when a sender attaches his/her preferences like the filename, size 
etc for the email attachments, a normal user would either not bother for 
this level of details or provide a bit more care while changing 
disobeying the  recommendations or accept the MUA action and accept most 
of the headers as is, without much further efforts(this would definitely 
be implementation dependent though), while the originality and history 
of the content has good chance to be retained in this case. For rest of 
the users, when recipients, it would still be available to be tempered. 
However, from the senders perspective it would become quite meaningful.

So far the suggestion seems to gather mixed feelings. I would be 
grateful to have more comment and critics about this.

Thanks Much for your time.

Regards,
Tanu.