Subject: Re: Standardize Complaints-To as deployed?

From: Russ Allbery <[email-masked]>
Date: Mon, 01 Nov 2004 17:44:17 -0800

(Catching up from having been on vacation.)

Charles Lindsey <[email-masked]> writes:

> No software generates this header, but lots of software generates the
> X-Complaints-To header (and for email too, I believe), which is
> essentially identical (but we cannot standardize X-headers).

I would be curious to know what software other than INN generates
X-Complaints-To.  It, like X-Trace, is an INN invention, and I don't know
if anyone else has copied it.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Nov 2004 12:37:32 +0000

>if anyone else has copied it.
<chair hat off>
At this time I am tempted to say that X-Complaints-To is deprecated and 
it is function is incorporated into Injection-Info.
</chair hat off>

Alexey

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 2 Nov 2004 17:00:11 GMT

>if anyone else has copied it.

A quick poke around part of my newspool revealed 90% of articles using
X-Trace, and 40% using X-Complaints-To.

Harder to tell which of those were or were not using INN as injecting
agent, but I then grepped for Paths of the form
...!example.net.POSTED!not-for-mail, which I think can safely be assumed
*not* to have used INN for injecting, and I found examples of the
following forms:

202932:X-Complaints-To: [email-masked]
203490:X-Complaints-To: [email-masked]
203451:X-Complaints-To: [email-masked]
203105:X-Complaints-To: [email-masked]
202898:X-Complaints-To: [email-masked]
203455:X-Complaints-To: [email-masked]
202656:X-Complaints-To: [email-masked]
203485:X-Complaints-To: [email-masked]
202848:X-Complaints-To: [email-masked]
202900:X-Complaints-To: [email-masked]
202833:X-Complaints-To: http://www.ntlworld.com/netreport

and in a separate bit of grepping:
X-Complaints-To: [email-masked]

Don't worry about the ntlworld one. They are known to be terminally
clueless :-( .

Perhaps Bill Davidsen could comment on what Prodigy are using.

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

---

From: Russ Allbery <[email-masked]>
Date: Tue, 02 Nov 2004 09:30:54 -0800

> *not* to have used INN for injecting, and I found examples of the

Not a safe assumption.

> Perhaps Bill Davidsen could comment on what Prodigy are using.

Prodigy ran INN at least in part, last I'd heard.

The count of X-Trace in your sample is suspiciously high, causing me to
suspect the integrity of your sample.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 02 Nov 2004 21:00:31 +0100

Alexey Melnikov wrote:

> I am tempted to say that X-Complaints-To is deprecated and

Good riddance.  But how am I supposed to derive an abuse
address from the Injection-Info ?  Without the old examples
the new Usefor-01 is gibberish for me.

Add news@ to the path-identity maybe ?  Is that guaranteed
to be good for Injection-info ?  What about a news@ wanting
abuse reports sent to another address like abuse@ ?

For your idea we need at least an example and instructions.
4.1.4 in Useage doesn't help to understand Injection-Info.

Usefor-13 before the split was monstrous, OTOH it was clear.
It's no more fun to read the split drafts.

                         Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Nov 2004 12:07:12 +0000

>4.1.4 in Useage doesn't help to understand Injection-Info.
Of course, this would be addressed in the upcoming USEFOR document.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Nov 2004 12:10:56 +0000

> Of course, this would be addressed in the upcoming USEFOR document.

Just to clarify: in my original message I was talking conceptually. All 
affected document will have to be updated.

(And I was talking about adding a new field to Injection-Info that would 
contain an email address.)

---

From: Richard Clayton <[email-masked]>
Date: Wed, 3 Nov 2004 15:32:22 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>X-Trace, and 40% using X-Complaints-To.

I have a database of approximately 25 million article headers dating
from July 26 through to October 18th (this is pretty much a "full feed"
of non-binaries for this period: I gathered them from an experimental
system running next to the !demon! peering machine)

Of these...

         3,620,184 (13.8%) have X-Trace 
         1,033,266 ( 4.0%) have X-Complaints-To
        14,422,971 (55.2%) have both
         7,049,506 (27.0%) have neither 

>202833:X-Complaints-To: http://www.ntlworld.com/netreport

there's all sorts of other stuff out there...  eg

   X-Complaints-To: Please report abuse to [email-masked]

but the overwhelming majority are valid looking email addresses. If it
is useful I could give an account of what proportion were nicely formed

BTW "X-Trace" is a complete mess to parse automatically, so it's use to
anyone other than the injection site is limited (and it may in some
cases not assist over-much in identifying that site)

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 3 Nov 2004 12:15:55 GMT

>the new Usefor-01 is gibberish for me.

Presumably there would be another parameter to the Injection-Info header
of the form:

Injection-Info: foo.net; ... ; complaints-to="[email-masked]"; ...

Indeed, that was the original proposal when Injection-Info was first
mooted, but the WG decided that it wanted a separate Complaints-To header.

I would prefer to stay with that.

I think it depends on which headers the "ordinary user" actually needs to
see. It could be argued that the rest of the Injection-Info header is
mostly for geeks, rather than for ordinary users.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 03 Nov 2004 23:39:42 +0100

Alexey Melnikov wrote:

> I was talking about adding a new field to Injection-Info

Okay, then it's clear, and Charles said the same.  I like
this proposal, it's less trouble to catch _one_ forged
header with all the injection info (for injecting agents).

The geeks will love it, as Charles said, and only geeks
need the complaint address.  And for spammers it's more
difficult to forge the complete Injection-Info.  Besides
I like KISS instead of "yet another header".  Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Wed, 03 Nov 2004 14:49:53 -0800

> I like KISS instead of "yet another header".  Bye, Frank

I'm not particularly a fan of Injection-Info, but I'm willing to keep it
around as a compromise and given that, I think it probably does make sense
to combine the two.

I still do think that the complaint parameter, however we represent it,
should be a URL rather than an e-mail address.  This is one of those
principals like not imposing arbitrary limits on fields.  A URL is more
general and more flexible than an e-mail address; I don't know if, ten
years down the road, we'll regret having only an e-mail address or will
want a URL, but I don't see any reason to risk it.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 04 Nov 2004 15:50:28 +0100

Russ Allbery wrote:
 
> I'm not particularly a fan of Injection-Info, but I'm willing
> to keep it around as a compromise and given that, I think it
> probably does make sense to combine the two.

And I'm no fan of your URL idea, but with a MIME parameter in
Injection-Info you're very near to your goal:  You could use
the format in RfC 2017 with its folding rules.  Don't mention
RfC 2231, or I'd continue my whining about complaint URLs ;-)

> not imposing arbitrary limits on fields.  A URL is more
> general and more flexible than an e-mail address; I don't
> know if, ten years down the road, we'll regret having only
> an e-mail address or will want a URL

That's why you want a URL, because we'll regret it as soon as
it's available.

Injection-Info:
  stuff; more=stuff; abuse-reports*1="mailto:"
  abuse-reports*2="news%40funny.example"
  abuse-reports*3="?subject=complaint%20about%20"
  abuse-reports*4="Message-ID%20%3Crandom+timestamp%40"
  abuse-reports*5="spammer.domain.example%3E&Cc="
  abuse-reports*6="abuse%40news.funny.example"

Flexible indeed.  And several pages of security considerations
plus an appendix I "IRIs in the abuse-reports parameter of
Injection-Info".  At least nobody wanted XML and a schema for
Injection-Info, today you never know ;-)

                          Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 04 Nov 2004 08:25:11 -0800

> Flexible indeed.

How is this any worse than not providing a complaints-to address at all?

Most of what makes that look like such a mess, of course, is the decision
to use MIME-style parameters for Injection-Info, not anything about the
content of the abuse-reports parameter.

> And several pages of security considerations plus an appendix I "IRIs in
> the abuse-reports parameter of Injection-Info".

I believe that the security considerations of visiting URLs are already
dealt with in adequate depth by other RFCs that we can simply refer to,
although I've not checked personally.

However, if people would prefer to have both an email and a url parameter,
that would also be fine with me.  And I have no problem with lots of
ranting against using anything other than a simple mailto URL in the
USEAGE document.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 4 Nov 2004 16:20:04 GMT

>want a URL, but I don't see any reason to risk it.

The people who were arguing against URLs were really arguing against URLs
that pointed to web sites (like the ntlworld one that I quoted). It needs
to be made clear that Netnews and the Web are different media, and things
must be so that a user who has News access but no Web access is not
disadvantaged.

Now if we were to restrict the URL to be only 'mailto', then I might buy
it, but then you have the problem that if you give them an inch the more
clueless providers out there will just take a mile and use 'http' URLs,
legally or not. So my preference is to leave it as just the email address
(and using a Complaints-To header just to emphasise the point).

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 4 Nov 2004 16:23:43 GMT

>is useful I could give an account of what proportion were nicely formed

For a header that is nowhere documented officially, that is not bad going.
Of course, if we bless it with standardization, then the malformed ones
should wither away over time (and with the throwing of suitable LARTs).

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 05 Nov 2004 13:16:33 +0100

Russ Allbery wrote:

 [weird mailto: abuse URL as multiline 2231 parameter] 
> How is this any worse than not providing a complaints-to

The alternative is a plain mailbox address, not "no abuse
address at all".
 
>> several pages of security considerations plus an appendix I
>> "IRIs in the abuse-reports parameter of Injection-Info".
 
> I believe that the security considerations of visiting URLs
> are already dealt with in adequate depth by other RFCs that
> we can simply refer to,

Probably, 2396bis is already in the RfC-editor queue.  But I'm
lost with IRIs, all I know for sure about IRIs is "this doesn't
work with my good old Mozilla 3 without UTF-8".

> However, if people would prefer to have both an email and a
> url parameter, that would also be fine with me.

That would cover GMaNe, your article has the following headers:

X-Complaints-To: [email-masked]
X-Trace: sea.gmane.org 1099585603 14799 80.91.229.6
	 (4 Nov 2004 16:26:43 GMT)
NNTP-Posting-Host: deer.gmane.org
NNTP-Posting-Date: Thu, 4 Nov 2004 16:26:43 +0000 (UTC)
X-Report-Spam:
	 http://spam.gmane.org/gmane.ietf.usenet.format:27779

Please don't click on the link, "unreporting" reported spam
with GMaNe can be tricky.  With both formats in Injection-Info
GMaNe could replace four headers by a single header.  And it
would be easy to replace this stuff if it's reinjected somehow
elsewhere.
              Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 05 Nov 2004 13:33:02 +0100

Charles Lindsey wrote:

> Of course, if we bless it with standardization, then the
> malformed ones should wither away over time (and with the
> throwing of suitable LARTs).

A new Whatever: doesn't exist yet, and as soon as it exists
getting rid of a few malformed Whatever: should be easy.

But IMHO you can't "deprecate" old X-Whatever:, because I'm
free to invent and use X-Whatever: in any form I like.  No
X-Whatever: can be "malformed", it's unstructured gibberish.

I've seen the same idea of "deprecating" X-Archived-At:, but
AFAIK that's not how it's supposed to work.  Please correct
me if my idea of X- headers is wrong.

                            Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Fri, 05 Nov 2004 09:12:33 -0800

> X-Whatever: can be "malformed", it's unstructured gibberish.

Headers beginning with X-* have no special meaning or significance as of
RFC 2822.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 05 Nov 2004 09:11:59 -0800

> The alternative is a plain mailbox address, not "no abuse

Why do you think that?  I don't understand why anyone thinks that banning
URLs is going to convince ISPs to provide plain mailbox addresses as abuse
reporting venues when they wanted to use a web form.  If I were an ISP
convinced I wanted to use a web form, requiring an address would just mean
that I didn't provide that parameter and instead added some other header
with the URL.

I understand the behavior that people want to modify here, but the way in
which people are trying to go about modifying behavior is, frankly, not
going to work, and hurts our future flexibility.

> 	 http://spam.gmane.org/gmane.ietf.usenet.format:27779

The Gmane X-Report-Spam header is something completely different than what
we're talking about, unless I'm seriously mistaken as to what it's for.  I
believe that it is for collaborative spam filtering, not for abuse
complaints.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 05 Nov 2004 21:04:31 +0100

Russ Allbery wrote:

> If I were an ISP convinced I wanted to use a web form,
> requiring an address would just mean that I didn't provide
> that parameter and instead added some other header with the
> URL.

And I'd use mail to news@, usenet@, and abuse@ anyway.  Maybe
with a copy to nanas, depends on how upset I am.  If you think
that URLs are no problem no matter what the RfC says, then why
officially sanction it ?  Alexej's idea was to get rid of the
dubious Complaints-To: instead of the common X-Complaints-To:,
and the latter is a mailbox address (minus the one case of bad
prosa found by Charles).

> I understand the behavior that people want to modify here

It's not a modification, at the moment there are no URLs in
X-Complaints-To:

 [Gmane X-Report-Spam]
> I believe that it is for collaborative spam filtering, not
> for abuse complaints.

Yes, it's related to spam filtering, the admins see reported
links, and if they confirm it the article is deleted, or the
pseudo-group gmane.spam.detected is added to the Newsgroups:,
I'm not sure.  It's essentially what I'd expect from your URL
idea.  And reporting spam is a form of abuse complaint.

                             Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Fri, 05 Nov 2004 12:47:11 -0800

> idea.  And reporting spam is a form of abuse complaint.

You and I seem to be talking about such completely different things that
I'm not quite sure what more to say.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 5 Nov 2004 17:36:12 GMT

>> Flexible indeed.

Ah! An ideal format for those providers who don't actually want anybody to
send them any abuse reports :-) . And who will not recognize

Subject: complaint%20about%20Message-ID%20%3Crandom+timestamp%40spammer.domain.example%3E&Cc=abuse%40news.funny.example

if some naive user just cuts and pastes it from the URL like that.

Actually, there is no real reason ever to use the RFC 2231 parameter
splitting in News, because we do not allow transports to arbitrarily
refold anythong over 78 characters in length, and quite honestly I would
rather see

Injection-Info: stuff;
  more=stuff;
  abuse-reports="mailto:[email-masked]?subject=complaint%20about%20Message-ID%20%3Crandom+timestamp%40spammer.domain.example%3E&Cc=abuse%40news.funny.example"

on one long line and view it with whatever wrapping/scroolbar/etc my
browser provided me with.

>How is this any worse than not providing a complaints-to address at all?

But nobody is suggesting that. The alternative suggestion is just an email
address (and preferably to my taste in a Complaints-To header).

>ranting against using anything other than a simple mailto URL in the

I don't want "ranting against". I would want MUST NOT.

---

From: Russ Allbery <[email-masked]>
Date: Fri, 05 Nov 2004 19:40:55 -0800

> refold anythong over 78 characters in length, and quite honestly I would

We need to stay compatible with mail.

> But nobody is suggesting that. The alternative suggestion is just an
> email address (and preferably to my taste in a Complaints-To header).

This may be the case in the ideal world that you're imagining, but in
practice that won't be how it works.  You are not going to convince a site
that does not want to provide an e-mail abuse reporting address to provide
one by not allowing them to provide a URL.

> I don't want "ranting against". I would want MUST NOT.

Then we have an irreconcilable difference.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 06 Nov 2004 16:46:40 +0100

Charles Lindsey wrote:
 
> there is no real reason ever to use the RFC 2231 parameter
> splitting in News

That's also true without the "in News" (at least for URLs).  

> we do not allow transports to arbitrarily refold anythong
> over 78 characters in length

Yes, and we'd need Martin Dürst to force some encoded words
into the URL (or for an IRI).  The German translation of
"complaint about" would be "Beschwerde über", but I have no
idea how to put "ü" in a mailto-URL within a MIME parameter.

> I don't want "ranting against". I would want MUST NOT.

I'd like to know how this is supposed to work, resulting in
MUST NOT if it doesn't work.  Otherwise (= Bruce and Martin
can solve the "ü" puzzle, and their solution is identical)
I could live with SHOULD NOT.
                              Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 6 Nov 2004 05:15:28 -0500

> Headers beginning with X-* have no special meaning or significance as of

There is a significant difference per (full Standard) RFC 822.
RFC 2822 is merely a Proposed Standard; RFC 822 remains
in effect and will continue to do so until such time as an
RFC 2822 successor reaches full Standard status. There
is also an explicit part of RFC 2047 concerning user-defined
(X-) fields. RFC 2047 is a Draft Standard, one rung up the
Standards Track from Proposed Standard and one rung
below full Standard.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 6 Nov 2004 23:45:10 -0500

> That's also true without the "in News" (at least for URLs).  

No, URIs can easily be longer than 998 octets.  Of course, there's
no reason to use such parameters anywhere other than the two
specific MIME fields (Content-Type and Content-Disposition) for
which they're designed.
 
> idea how to put "ü" in a mailto-URL within a MIME parameter.

If you want to produce a prototype message:

To: [email-masked]
Subject: =?iso-8859-1*de?q?Beschwerde_=FCber?= <[email-masked]>

then a corresponding mailto URI is:

mailto:[email-masked]?Subject=%20%3D%3Fiso-8859-1*de%3Fq%3FBeschwerde_%3DFCber%3F%3D%20%3C123%40example.org%3E

Depending on which version of the mailto URI specification and
which version of URI syntax you're using, the '@' might be URI
encoded as "%40".

The above URI in an RFC 2231 parameter with attribute name
uri could appear as:

 ; uri*0="mailto:[email-masked]?Subject=%20%3D%3Fiso-8859-1*de%3Fq%3FBeschwerde_%3D"
 ; uri*1=FCber%3F%3D%20%3C123%40example.org%3E

Note that it is not necessary to specify a charset or language for
the uri parameter since a URI is always in a subset of ANSI X3.4
and is a protocol string not text.  If nevertheless one specified an
explicit charset, each '%' in at least the first parameter fragment
would have to be RFC 2231 encoded (as would ':', '@', '?', and '='):

 ; uri*0*="ISO-ir-6''mailto%3Aabuse%40example.org%3FSubject%3D%2520%253D%253Fiso-8859"
 ; uri*1=-1*de%3Fq%3FBeschwerde_%3DFCber%3F%3D%20%3C123%40example.org%3E

RFC 2047 encoded-words (as amended by RFC 2231 and errata)
are clearly defined, mailto URI and generic URI syntax have some
warts but one can construct a safe mailto URI, and constructing
RFC 2231 parameters is also possible if one has tools to do so.
However, each successive step adds another layer of encoding;
RFC 2047 '=' and '?' interact with URI syntax and have to be
encoded, and URI '%', ':', '?', and '=' interact with RFC 2231
parameter encoding and have to be encoded.  By the time one
finishes with all of that, it's barely recognizable.  And there's a
more serious problem; how is an end user going to make use of
this mess?  I know of no facilities in UAs for extracting and
recombining arbitrary RFC 2231 parameters in arbitrary fields.
Some UAs do have capability to follow URIs in message header
fields, although it may require some contortions to get some of
those UAs to do so.

> > I don't want "ranting against". I would want MUST NOT.

With no interoperability issues and no network damage issues,
RFC 2119 "MUST NOT" is out of the question.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Nov 2004 21:46:21 +0100

Bruce Lilly wrote:

> URIs can easily be longer than 998 octets.

Yes, but they don't contain unencoded white space, therefore
the folding rules in RfC 2017 3.1 are good enough.  IIRC it
was you who posted pointers to all relevant RfCs incl. 2017.

> mailto:[email-masked]?Subject=%20%3D%3Fiso-8859-1*de%3Fq%3FBeschwerde_%3DFCber%3F%3D%20%3C123%40example.org%3E

Thanks, so you added the language to the MIME encoded Subject,
not to the MIME parameter.  And it even works with my good old
Mozilla 3 (of course it has no idea what *de should be :-).

> Depending on which version of the mailto URI specification
> and which version of URI syntax you're using, the '@' might
> be URI encoded as "%40".

I can see this fascinating thread on the URI list.  It gets
weird if you try to redirect percent encodigs through PURL:
http://purl.net/xyzzy/-AWFID/imperial%2520ton/35%2520in%2520oz

> RFC 2119 "MUST NOT" is out of the question.

That wasn't meant literally.  The real question is mailbox
address vs. URL in the possible abuse-reports= parameter of
Injection-Info.  Let's just offer both and be done with it.

                            Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 7 Nov 2004 16:32:02 -0500

> was you who posted pointers to all relevant RfCs incl. 2017.

RFC 2017 [3.1] applies only to a specific parameter in the
Content-Type field when used with a specific media type.
It's also based on RFC 1738, the relevant parts of which
have been superseded by RFC 2396 (which uses different
syntax), which may itself be replaced by yet another
different syntax specification.  Now it might be possible
to incorporate the same principles used in RFC 2017,
but it won't be as simple as referring to 2017 (because
it's not applicable) or copying some text from 2017
(because the underlying URL syntax used by 2017 is
obsolete and the current syntax is quite different).

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 07 Nov 2004 23:24:51 +0100

Bruce Lilly wrote:

> it might be possible to incorporate the same principles used
> in RFC 2017,

Good enough, or at least better than the 2231 idea of folding.

> because the underlying URL syntax used by 2017 is
> obsolete and the current syntax is quite different.

Okay, I try it, old:

| URL-parameter := <"> URL-word *(*LWSP-char URL-word) <">
| URL-word := token

New: 

| URL-parameter := DQUOTE URL-word *( [FWS] URL-word) DQUOTE
| URL-word      := 1*( %d33 / %d35-126 )
|                  ; the concatention of the URL-words yields
|                  ; an URI as defined by [2396bis]

We don't need \" here when we have %22, or do we ?  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Nov 2004 13:59:32 GMT

>X-Whatever: can be "malformed", it's unstructured gibberish.

No, you can't forbid it formally, but you can say "The new Whatever header
SHOULD be used in place of the previously used, but nowhere documented,
X-Whatever header" (which is actually what we currently say in respect of
the new Injection-Info and the old NNTP-Posting-Host and X-Trace).

That doesn't render the old forms non-compliant, but it provides good
ammunition for directing flames and LARTs at sites that haven't changed
their ways several years after the new standard was adopted.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Nov 2004 14:10:15 GMT

>that I didn't provide that parameter and instead added some other header

If we are agreed that it is a Bad Thing for ISPs to be requiring users to
use web forms for abuse complaints (and I think we are, and the consensus
on the news.net-abuse.* groups supports us), then the first thing you do
is to ensure that the syntax provided in your complaints-header does not
afford them that opportunity. That means they are forced to use
undocumented X-headers for the purpose, which leaves them wide open to
peer pressure, flames and LARTs to make them change their ways.

As for the mailto URL scheme, its only benefit seems to be that the ISP
can insert a Subject in it to help identify the source of the abuse (which
leads to all sorts of strange subjects in strange languages and encodings
such as Bruce has shown to us).

Far better to encode such information in the local-part of the abuse
address, as in

Complaints-To: [email-masked]

where "123456" is some logging information meaningful to the ISP inserting
it, of even a msg-id (if you can mangle it so as to be a legal
local-part).

---

From: Russ Allbery <[email-masked]>
Date: Mon, 08 Nov 2004 09:59:32 -0800

Charles Lindsey <[email-masked]> writes:

> If we are agreed that it is a Bad Thing for ISPs to be requiring users
> to use web forms for abuse complaints (and I think we are, and the
> consensus on the news.net-abuse.* groups supports us),

I don't actually agree with this.  I just think it's pointless to try to
argue it with the people here.

> then the first thing you do is to ensure that the syntax provided in
> your complaints-header does not afford them that opportunity.

This is putting policy that might change into the standard.  I think this
is a hideously bad idea for all of the reasons that I've previously stated
and that have been discussed on the mailing list for the last three or
four years, the same reasons that have resulted in splitting the policy
document off to USEAGE.

---

From: Thorfinn <[email-masked]>
Date: Tue, 9 Nov 2004 19:53:20 +1100

On Mon 08 Nov 2004 at 09:59:32AM -0800, in <[email-masked]>,
> argue it with the people here.

FWIW, I don't agree with it either.  I see a good reason for us to
strongly recommend a mailto: in preference to any other sort of URL, but
I don't think there's a strong reason to prevent ISPs from putting in a
http: url if they want to.

Later,

  Thorf

-- 
<a href="http://tertius.net.au/~thorfinn/">[email-masked]</a>
~/ For those who've come across the seas, ~/ We've boundless plains to share, ~/
~/   With courage let us all combine,     ~/    To Advance Australia Fair.    ~/
     -- The end of the second verse of the Australian National Anthem. --

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 9 Nov 2004 11:00:51 GMT

>argue it with the people here.

With a mail abuse address, you can to a large extent automate the process
of sending a LART (e.g. by generating a mail message with the right To:
address and with the full headers already pasted into it; so you just have
to add some text explaining that this is a spam, or whatever).

But every web site interface is different. Each LART has to be constructed
by hand by a human, including cutting and pasting a set of full headers
into whatever box (usually too small) the web site deigns to provide.

Hence the suspicion, frequently voiced, that the ISPs concerned are really
trying to discourage you from complaining at all by providing unnecessary
hoops using a medium that may not be available to you.

>four years, the same reasons that have resulted in splitting the policy

Hideously bad it may be, but I don't think you are going to find
consensus on this list for anything else. If the climate changes in the
future (which I doubt), then an extension might be possible. That is
actually one advantage of putting it in Injection-Info, because you could
introduce a new parameter permitting URLs as a later extension.

OTOH, providing a Complaints-To header would simply be seen as adopting the
current usage of the X-Complaints-To header and, given its widespread
usage and almost universally agreed syntax, could hardly be objected to.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 9 Nov 2004 09:17:59 -0500

> We don't need \" here when we have %22, or do we ?  Bye, Frank

One problem is that there are many characters in %d33,%d35-%d126
which were "unsafe" in RFC 1738, "excluded" in RFC 2396, but in
RFC 2396bis there is no list of those characters that may not be part
or a URI (under any name).  Two examples are '<' (%d60) and '>'
(%d62), which are prominently used in RFC [2]822 address fields
and which therefore are likely to be part of content placed into a
mailto URI; moreover, under some mechanisms (e.g. RFC 2369
List- fields) those characters are used to delimit URIs.  If we're
going to handle general URIs (as we should), we need to be wary
of any interaction between particular URI schemes and the ever-
changing URI syntax.  For example, the mailto URI scheme
specification (RFC 2368) requires that "all URL reserved
characters in 'to' must be encoded"; whereas '@' was not "reserved"
in a URI path component (which is where the RFC 2368 production
"to" appears) under RFCs 1738 and 2396, it is unconditionally
"reserved" in RFC 2396bis.  That implies that '@' (%d64) must
be excluded from your "URL-word" grammar if we are considering
mailto URIs in isolation; other URI schemes may interact
differently with the generic URI syntax changes.  Because those
changes are still in a state of flux (no RFC obsoleting 2396 has
yet been issued), as that proposed changed syntax is not clearly
specified (no list of "unsafe" or "excluded" characters), and until
there has been some investigation of the effects of the proposed
changes on all URI schemes (and preferably after there has been
an adequate amount of practical experience with implementations
based on the changed syntax), IMO it would be premature to
attempt to formulate specific syntax.  The simplest and safest
course of action for the USEFOR WG would be to wait until the
responsible parties for the affected specifications have come to
agreement on revised syntax, then adopt that agreed-upon
syntax.  There is no urgent need to take action at this time; there
is no existing standardized "complaints-to" field that needs to
be addressed, and premature action is likely to result in
incompatibilities which would have to be repaired; past experience
has shown that once a specification (or interpretation of an
imprecise specification) is ensconced in news software code, it
can take a very long time to recover.

---

From: Thorfinn <[email-masked]>
Date: Wed, 10 Nov 2004 11:00:28 +1100

On Tue 09 Nov 2004 at 11:00:51AM +0000, in <[email-masked]>,
> In <[email-masked]> Russ Allbery <[email-masked]> writes:
[snippage]
> into whatever box (usually too small) the web site deigns to provide.

Huh?  If it's a URL, you (the ISP) just embed a message identifier of
some kind into the URL.  Complaining about it is as simple as clicking
on the URL, and voila, done, complaint registered, no user interaction
required.

> hoops using a medium that may not be available to you.

Less hoops.  Medium not available, maybe... But I think that's a
sufficiently rare occurrence these days (and getting rarer all the time)
as to be not worth legislating for.

> consensus on this list for anything else.

Well, I'm speaking up as being against consensus in that direction
(restricting solely to email address).

> If the climate changes in the future (which I doubt), then an
> extension might be possible. That is actually one advantage of putting
> it in Injection-Info, because you could introduce a new parameter
> permitting URLs as a later extension.

Now, that is, perhaps, a fair point, that it's easier to get people to
accept just taking the X- off.  I still think that getting them to take
the X- off and putting mailto: on the front is not a particularly
difficult task.

And reader agents are free to just ignore anything that isn't a mailto:...
I don't think we're putting any requirement on them to necessarily do
anything *with* a Complaints-To: header, are we?

Later,

 Thorf

---

From: Russ Allbery <[email-masked]>
Date: Tue, 09 Nov 2004 16:35:17 -0800

> the X- off and putting mailto: on the front is not a particularly

I can speak for INN's implementation in saying that removing the X- and
removing the X- plus adding mailto: are both equivalently difficult (and
are both trivial).  Implementing Injector-Info is harder, although not
that hard.  (Parsing Injector-Info is completely insane, but well, we knew
that going in.)

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 15 Nov 2004 11:27:01 GMT

In <[email-masked]> [email-masked] (Kai Henningsen) writes:

>[email-masked] (Charles Lindsey)  wrote on 09.11.04 in <[email-masked]>:

>There'll be no consensus for no-urls either.

Well I think all our arguments have been well rehearsed by now, so please
coud our CHair count heads and announce a decision.

Essentially, there are two issues to decide, more or less orthogonal:

1. Should the complaints address be given as an email address or as a URL
(with a side issue of whether any such URL be restricted to 'mailto'
only)?

2. Should whatever is done be done in the context os a Complaints-To
header, or in the context of an extra parameter to Injection-Info?

If anyone thinks they are not orthogonal (i.e. would vote differently on
one of them according to the result of the other, then please speak up).

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 15 Nov 2004 19:14:40 +0100

Charles Lindsey wrote:
 
> If anyone thinks they are not orthogonal (i.e. would vote
> differently on one of them according to the result of the
> other, then please speak up).

With "2" (Injection-Info) it's possible to have both options.
I'd say "no" to URLs unless there's an explicit folding rule
derived from 2017.  A simple mailbox address should be okay,
independent of any URL option.  Restricting URLs to mailto:
is a bad idea.
               Bye, Frank (Complaints-To: <about:mozilla> ;-)

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 16 Nov 2004 11:34:18 GMT

>independent of any URL option.  Restricting URLs to mailto:

OK, so I think you are suggesting the following possibilities:

1. Use Injection-Info with parameter mail-complaints-to=<address>
   (leaving the possibility open for a separate URL extension later).

2. Use Injection-Info with parameter mail-complaints-to=<address> AND with
   a separate complaints-url=<URL> (with explicit permission to fold it by
   inserting FWS/CFWS at any point, cf RFC 2017 ???).

3. Use Complaints-To with <address> only

4. Use complaints to with <address> OR <URL> (I think these can be
   distinguished syntactically fairly easily). Explicit permission to fold
   the URL as above.

Any other options anyone wants?

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 16 Nov 2004 23:45:48 +0100

Charles Lindsey wrote:

Only one minor point:

> complaints-url=<URL> (with explicit permission to fold
> it by inserting FWS/CFWS at any point, cf RFC 2017 ???).

Not CFWS, only FWS.  Bruce found IMHO no serious problem
in the proposed syntax, the details of RfC 2396bis like
reserved char.s are irrelevant for your draft and Usenet.

(Let the IESG and W3C fight it out if something in 2396bis
 doesn't work with mailto:, IRIs, zone IDs, or whatever ;-)

BTW, I asked the author of 2821 about the weird host TV,
it's intentionally at least one dot in SMTP domains,  Bye.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Nov 2004 17:06:44 +0000

>   inserting FWS/CFWS at any point, cf RFC 2017 ???).
(FWS, as noticed by Frank.)
I would prefer #2, followed by #1 and #3.

As a chair I would note that I see no consensus to use mail-complaint-to 
over complaints-url.

As a WG participant I would be Ok with saying that the 
"mail-complaint-to" SHOULD be present.

>   distinguished syntactically fairly easily). Explicit permission to fold
I don't think # 4 is a good architectural choice.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 19 Nov 2004 08:57:50 -0500

> Actually, there is no real reason ever to use the RFC 2231 parameter

Wrong. We have agreed that MIME is to be used, it is obvious that
mail<->news gateways exist, and RFC 2231 is part of the MIME
specification.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 19 Nov 2004 10:51:56 -0500

> one of them according to the result of the other, then please speak up).

They are not orthogonal (I might very well vote differently on
any one issue based on outcome of any of the others, if there
were separate independent votes). There are really six distinct
options involved in the three issues listed, as well as other
options that should be considered.

And before we get as far as an actual vote, we ought to set
some ground rules: there are many different voting systems,
each having distinct characteristics (e.g.
http://condorcet.org/emr/methods.shtml
), we need to agree on what options are to be voted on (should
include *all* viable options), on wording of the options (which
should be fair and representative), when voting will commence
and end, mechanics of the voting procedure, how results will
be used, etc.   For that matter, we ought to revisit the issue of
whether voting is an appropriate means for the Chair to assess
consensus.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 19 Nov 2004 11:11:16 -0500

> whether voting is an appropriate means for the Chair to assess

Confirming the last sentence: the IETF does not use voting to determine
consensus.

OK, OK, I know that we *do* use hums and straw polls, which may be
considered a form of voting, to help determine consensus.  See section 3.3
of RFC 2418 for guidelines describing what should be done to determine
consensus.  RFC 3929 may also be helpful for issues that are particularly
contentious.

-Scott-
(speaking as area advisor)

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 19 Nov 2004 09:23:17 -0500

On Tue November 16 2004 06:34, Charles Lindsey wrote:

>    distinguished syntactically fairly easily).

You are wrong; the syntax is very close and may pose problems for
some types of parsers.  If you really thought the syntax was easily
distinguishable, then you would have proposed a single parameter
rather than two parameters in #2.

>    Explicit permission to fold 
>    the URL as above.

RFC 2017 applies only to parameters in a Content-Type field;
is is inapplicable to any other field.
 
> Any other options anyone wants?

5. A separate field (complaints-to perhaps, but the tag name is a
   separate issue) specifying a URI. Handling of long URIs to
   be determined.

6. Table the matter and continue with more pressing business.
    Reconsider the matter when we have produced the two
    Standards Track RFCs that were supposed to have been
    produced a year ago.

7. Defer the matter to a general (not news-specific) header
   field.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 19 Nov 2004 14:49:50 GMT

>>OK, so I think you are suggesting the following possibilities:

Alexey has given his preference order as #2, #1, #3, #4.

Does this mean we are all supposed to express out preference order now? If
so, then my order is #3, #1, (|), #2, #4

The "(|)" in the middle is my consenus limit (i.e. I could live with
anything to the left of it, but would be most unhappy with anything to the
right).

>(FWS, as noticed by Frank.)

agreed.

>As a chair I would note that I see no consensus to use mail-complaint-to 

Nor does there seem to be any consensus for the opposite.

>"mail-complaint-to" SHOULD be present.

Ah! You mean that those who want to give a (non-mailto) URL SHOULD give a
mail-address as well. Yes, I could live with that

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 20 Nov 2004 07:37:33 +0100

Charles Lindsey wrote:

> my order is #3, #1, (|), #2, #4
 
  [Alexey wrote]
>> I would prefer #2, followed by #1 and #3.
[...]
>> "mail-complaint-to" SHOULD be present.

My preference is the same incl. this SHOULD and FWS folding.
Without FWS folding (= only 2231) it's #1 before #3.

I've seen Bruce's #5, #6, #7, but I don't like these ideas.

While Bruce and Scott discuss RfC 2418 I've another off topic
question:  My normal reaction to a poll is to send a private
mail, and then wait for the published result.  Is that how
it's supposed to work ?  With the IETF I never know, all this
"humming" in conjunction with RfC 3710 chapter 4.3 sounds like
"scientology" for me.  Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 20 Nov 2004 11:26:22 -0500

> (speaking as area advisor)

Just to avoid misinterpretation of my remarks as criticism of the Chair,
I'd like to clarify two points:
1. Although there was some concern about an early "60%" criterion,
   the Chair has since affirmed that voting is not intended to be used
   to determine consensus
2. The Chair did not initiate discussion of a "vote" or a euphemism
    for a vote (e.g. "count heads") in this matter.

Regarding "straw polls", my remarks about voting still largely apply;
we need to agree on methods, ensure that *all* points of view are
represented *fairly*, etc.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 20 Nov 2004 11:44:22 -0500

> > Any other options anyone wants?

8. A separate field whose field body specifies a list of URIs (so
    that multiple supported alternative methods of reporting abuse
    can be specified), perhaps something like the (incompletely-
    specified) List- fields of RFC 2369.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 20 Nov 2004 11:19:32 -0500

On Thu November 4 2004 11:20, Charles Lindsey wrote:

> It needs
> to be made clear that Netnews and the Web are different media,

As (regarding access to services and transport) news and mail
are different forms of transport.

> and things 

That is specious for two reasons:
1. we are discussing an Internet Standards Track RFC, which
    is applicable for the Internet and does not impose any
    requirements on non-Internet use of news.
2. within the domain of the specification (viz. the Internet),
    there is no reason to differentiate between HTTP, email,
    etc. access; they are all viable services -- under some conditions
   a particular group of users might have access to HTTP and NNTP
   (but not SMTP) or to NNTP and SMTP (but not HTTP) or to HTTP
   alone (and it is possible to read and post news via web interfaces).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Nov 2004 11:20:33 GMT

>> Actually, there is no real reason ever to use the RFC 2231 parameter

I should have been more specific and said I was refering particularly to
the case of the Archive and Injection-Info headers, which are
news-specific.

>mail<->news gateways exist, and RFC 2231 is part of the MIME

Sure, if cruft comes in from mail, then we have to accept it as it is. But
if you are writing an article for the news environment in the first place,
then my remark stands.

BTW, the USEFOR draft needs to make it clear that these parameters in the
Archive and Injection-Info headers are indeed subject to the usual rules
regarding MIME parameters, including RFC 2231.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Nov 2004 11:42:28 GMT

>some types of parsers.

I think you could easily distinguish them using no more than regular
expressions.

>  If you really thought the syntax was easily

I didn't propose it. It was Frank's idea (though a good idea IMO).

>is is inapplicable to any other field.

If we write in our standard that RFC 2017, or something like it, applies,
then it will apply.

>5....

>6. ...

>7. ...

Fine, include those if you like. I note that you have not actually
expressed any order of preference yet.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Nov 2004 11:27:14 GMT

>),...

It is ultimately up to our Chair how he uses straw votes to decide which
option has the best consensus. But if we give our preferences as an
ordered list of options, then the method devised by the Marquis de
Condorcet has much to commend it (we used that method once before when we
had a straw poll here, and it is regularly used with some success when we
have CFVs in uk.*).

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Nov 2004 11:37:55 GMT

>    requirements on non-Internet use of news.

Usenet is not a part of the internet, but 99% of Usenet traffic is in fact
carried on the internet, so it makes good sense to standardize it under
the auspices of the IETF. So far as I am aware, it has never been the case
that the IETF expects that all known internet protocols should be presumed
to be available to all internet users, and therefore internet standards do
not normally make such presumptions.

>2. ... -- under some conditions

Yes, but you know perfectly well that it is unusual for News users not to
have Email capability, whereas lack of access to the web is less uncommon
(for example to people using simple terminals or terminal emulators - I
have not tried filling in an abuse web form using Linx, but I doubt it
would be an easy task).

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 22 Nov 2004 16:17:42 +0100

Charles Lindsey wrote:

> the USEFOR draft needs to make it clear that these parameters
> in the Archive and Injection-Info headers are indeed subject
> to the usual rules regarding MIME parameters

That's documented elsewhere, don't mention it.

> including RFC 2231.

Never ever mention it, arguably it allows weird stuff like
boundary*0=next; boundary*1=" "; boundary*2=part

Somewhere it says "MUST NOT change the syntax", and the next
thing it does is to change the syntax.  I really don't like it.

| IMPORTANT NOTE:  These mechanisms end up being somewhat 
| gibbous when they actually are used. As such, these
| mechanisms should not be used lightly; they should be
| reserved for situations where a real need for them exists.

With the simple rule "remove FWS and concatenate" for URLs
there is no real need for RfC 2231, just use the syntax in
<http://article.gmane.org/gmane.ietf.usenet.format/27798>

Can we get rid of the new "filename" parameter of "Archive" ?

Common practice is X-NoArchive: yes, and that's of course
weird, but the only relevant case.  Almost nobody (*) uses
"Summary" or "Keywords", and another irrelevant "filename" in
a new "Archive" won't fly.  Martin's new "Archived-At" is a
good idea, and Usenet will inherit it.

Without the dubious "filename" in a completely new "Archive"
you'd have eliminated the last reason to mention RfC 2231, and
that's a good thing.
                      Bye, Frank

*: for "almost nobody uses it" read "I don't use it" ;-)

---

From: Henry Spencer <[email-masked]>
Date: Mon, 22 Nov 2004 10:42:14 -0500 (EST)

On Mon, 22 Nov 2004, Charles Lindsey wrote:
> had a straw poll here...

Yes, and unfortunately, that one use also showed a big disadvantage of
this method:  interpretation of the results is non-trivial and is prone to
misunderstandings by those unfamiliar with the method.  On the whole, I
fear that a simpler method (e.g. approval voting:  mark X on every option
you can live with) is preferable. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 23 Nov 2004 11:03:09 GMT

>you can live with) is preferable. 

If you include, in your list of preferences, the point at which "I could
live with the ones above this, but not those below", then you have enough
information to analyze the results either way (and that is more or less
how it was done on the last occasion).

One of the nicest features of Condorcet's scheme is that there is nothing
you can do by way of sneaky "tactical voting" that will bring you any
advantage over what you get by giving your honest opinion of which order
your preferences lie in.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 23 Nov 2004 11:40:07 GMT

>That's documented elsewhere, don't mention it.

No, it isn't documented elsewhere. It is documented as regards the
Content-Type header in RFC 2045 (+2231) and as regards the
Content-Disposition header in RFC 2183 (+2231). But nowhere does it say it
applies to the Archive header and the Injection-Info header. So it needs a
few words in USEFOR to make it clear.

>boundary*0=next; boundary*1=" "; boundary*2=part

I think it has to be mentioned, because such constructs are going to turn
up from mail (certainly in Content-Type and Content-Disposition). Moreover
we might get files names or Injection-info parameters in non-ASCII
charsets, and these also rely on RFC 2231. And Bruce Lilly will be
screaming blue murder if we don't mention it (and for once I might agree
with him :-( ).

But I agree that there should never be a need to use the extended line
feature in News, and I would have no problem if USEFOR were to point this
out.

>thing it does is to change the syntax.  I really don't like it.

No, the strange things introduced by RFC 2231 were already legal under RFC
2045. It's just that some strange parameters that noone was ever likely to
write in Real Life suddenly acquired a new semantics. The same is true of
RFC 2047.

>good idea, and Usenet will inherit it.

No, Martin's "Archived-At" doesn't do quite the same thing.

Agreed the filename parameter of our Archive header is of no interest to
Google. But one can foresee other applications for this header (and one I
have particularly in mind is the Archive pseudo header currently used by
the news.answers moderators, which is actually a part of the body and
comes unstuck if ever you want to write a FAQ as a multipart (e.g. as a
miltipart/digest); so I think the news.answers people are going to have to
move to something different sooner or later anyway.

And, in any case, it is unlikely that a filename parameter will ever be so
long as to need RFC 2231 splitting, and I would still prefer it to extend
beyond 79 characters (whatever) than to split it. And that too could be
pointed out in USEFOR.

---

From: Henry Spencer <[email-masked]>
Date: Tue, 23 Nov 2004 15:43:27 -0500 (EST)

On Tue, 23 Nov 2004, Charles Lindsey wrote:
> >...interpretation of the results is non-trivial and is prone to
> information to analyze the results either way...

If you analyze *both* ways, that makes the results *still more* complex,
and still more prone to misinterpretation by people unfamiliar with
non-traditional voting schemes.  My point is that we need something which
yields *simpler* results. 

Yes, Condorcet's scheme has advantages.  But its complexity also incurs
serious practical disadvantages in this context, and it seems to me that a
simpler scheme is preferable despite being theoretically inferior. 

Classical vote-for-only-one definitely is *too* simple for a multi-way
choice.  But remember that what we are after, as an IETF WG, is not
necessarily the best solution, but a workable one that most people can
live with.  So indicating which choices you can live with is the important
part in a consensus-assessing poll.  Only if there are multiple choices
which are about equally acceptable do we have any need to consider whether
there's a consensus preferring one or the other.  To my mind, it seems
preferable to handle such a case -- should it arise -- by just conducting
a second tie-breaker poll.

                                                          Henry Spencer
                                                       [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Nov 2004 04:22:49 +0100

Charles Lindsey wrote:

> we might get files names or Injection-info parameters in
> non-ASCII charsets, and these also rely on RFC 2231.

Not really, you could say 2047 where you said 2045 + 2231,
2231 has nothing to do with character sets.

> Bruce Lilly will be screaming blue murder if we don't
> mention it (and for once I might agree with him :-( ).

Unfortunately I forgot the second part of 2231 with the
language tags for 2047, and that part is okay, in fact I
like it.  But the first part is a PITA.

> I agree that there should never be a need to use the
> extended line feature in News

Then let's get rid of the filename parameter in Archive,
otherwise it is necesseary.

> the strange things introduced by RFC 2231 were already
> legal under RFC 2045.

I've never seen a boundary*0=something in the wild, and
it would break "some" user agents and spam filters.  What
a wonderful toy for spammers and worm authors, :-(

> Martin's "Archived-At" doesn't do quite the same thing.

It does something useful, it establishes a "Permalink"
(that's hacker slang for a URL meant to stay some time)

> the filename parameter of our Archive header is of no
> interest to Google.

It's of no interest for everybody, it's much less relevant
than any X-Face, and we don't specify a new Face: header.

> I have particularly in mind is the Archive pseudo header
> currently used by the news.answers moderators

Okay, let's assume that the WWW does not exist, and that
you are a collector of FAQs posted in news.answers:  They
have already a working solution for their problem, if it
ain't broken don't fix it.

Back to the 3rd millenium, the WWW exists, Martin's idea
is good, and a standard way to propose filenames for FAQ
collectors comes at least 10 years too late for everybody.

> the news.answers people are going to have to move to
> something different sooner or later anyway.

They run on auto-pilot, they are no people, they are bots.
I tried to reach a human being at faqs.org, because links
to the plain text RfC versions don't work => forget it.

> it is unlikely that a filename parameter will ever be so
> long as to need RFC 2231 splitting

Maybe it wants a RfC 2231 language, that's not much better.

The concept of proposing a filename for a posted file is
dubious, the I-D list and the RfC-editor list work without
posting files.  Newsgroups with binaries apparently also
work without this "feature" (but don't ask me how).

> I would still prefer it to extend beyond 79 characters
> (whatever) than to split it

There, it doesn't work on my FAT partitions, but it needs
its own section in the security considerations.  Please
let's get rid of it, there's a limit for pretending that
the WWW doesn't exist, proposed filenames are beyond it.

                       Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 24 Nov 2004 08:07:13 -0500

> 2231 has nothing to do with character sets.

No, RFC 2047 (as amended by RFC 2231 and errata) applies
only to human-readable content, viz. unstructured fields,
comments, and RFC [2822] phrases.

> (that's hacker slang for a URL meant to stay some time)

It's not at all clear how that would work on Usenet; it's
defined in terms of a mailing list, where a single host
(the list expander) makes an archive copy, then
redistributes the message.  Usenet messages are
archived all over the place, by multiple sites at various
points during propagation.  If an Archived-At field
could be added at any time, there will be multiple
copies of what is ostensibly the "same" message, with
different sets of fields pointing to different places.

> than any X-Face, and we don't specify a new Face: header.

I tend to agree with Frank here.
 
> collectors comes at least 10 years too late for everybody.

It's not about file names per se, but about URIs for
accessing messages.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 12:21:36 +0000

>not normally make such presumptions.
I've participated in an IAB Workshop on Messaging recently and several 
participants have expressed wish to be able to tie different protocols 
together: access resources of one in another, etc. This suggest strong 
user's desire for protocol convergence.
I think new standards should not make such convergence more difficult.

>have not tried filling in an abuse web form using Linx, but I doubt it
Maybe there is a need in "abuse web form considered harmful" document. 
But this is generally not an argument against URLs.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 12:28:03 +0000

>   the Chair has since affirmed that voting is not intended to be used
That is correct. A good technical argument always wins.

>    for a vote (e.g. "count heads") in this matter.
No, I didn't initiate voting.

>represented *fairly*, etc.
My personal opinion on "straw polls" is that
1). they help to see if people has changed their mind during recent 
discussions
2). they are useful to make a decision when there is no strong technical 
argument(s) to choose one solution over another.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 12:15:47 +0000

>>consensus on the news.net-abuse.* groups supports us),
One can't force the market. People have tried to do that many times, but 
I don't remember any successful attempt.

>four years, the same reasons that have resulted in splitting the policy
I agree. We should keep policy separate, or we might regret our policy 
choices made-into-standard down the road.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 11:18:08 +0000

>on the URL, and voila, done, complaint registered, no user interaction
And there are many RPC proposals that run over HTTP transport (not that 
I am advocating their usage). So the argument that this is difficult to 
automate doesn't seem convincing.

>anything *with* a Complaints-To: header, are we?
Correct.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 11:30:23 +0000

>    specified) List- fields of RFC 2369.
I just want to note that I would like to be able to have multiple URIs. 
Whether they are in a separate header or part of the Injection-Info 
header - this is secondary to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Nov 2004 12:32:11 +0000

>so, then my order is #3, #1, (|), #2, #4
No, I didn't start a straw poll, but people can express their opinion at 
any time (opinion can be sent directly to me, if you prefer).
If we all just happen to magically agree, we can move on to more 
interesting topics.

>Nor does there seem to be any consensus for the opposite.
Yes, I meant both statements.

>mail-address as well. Yes, I could live with that.
>  
>
Yes.
Note, that this SHOULD belongs to USEAGE.
And I am strictly against it becoming a MUST.

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 25 Nov 2004 13:18:38 -0500

On Mon November 22 2004 06:37, Charles Lindsey wrote:

> So far as I am aware, it has never been the case 

Specifying use of a URI does not equate to making any such presumption.

> have Email capability,

Not so; I know of a number of ISPs that block outbound port 25
(SMTP) connections.

> whereas lack of access to the web is less uncommon 

I know of no ISPs that block outbound connections to port 80
(HTTP).

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Nov 2004 21:57:02 +0100

> I just want to note that I would like to be able to have

If we take the complaint-url= solution, we could simply allow
zero or more of these constructs in Injection-Info.  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Nov 2004 22:30:41 +0100

Bruce Lilly wrote:

> RFC 2047 (as amended by RFC 2231 and errata) applies  only to
> human-readable content, viz. unstructured fields, comments,
> and RFC [2822] phrases.

Yes, I've found it now in RfC 2231.  Sneaky, adding the "*" to
existing parameters they avoided to define a new MIME version.

 [Archived-At]
> It's not at all clear how that would work on Usenet

For something "posted" with Groups.Google it's possible, but it
makes more sense for special servers like news.gmane.org (with
its own archive) or news.spamcop.net (news2mail gateway with a
pipermail archive), i.e. in cases where the Message-ID is not
always enough to find old articles.

For Usenet it's probably irrelevant, unless users have their
own public archive of posted articles.  In the case of FAQs it
could be as simple as an faqs.org URL or any FAQ homepage.

> I tend to agree with Frank here.

Fine, that could eliminate filename=, and any 2231 filename*=
or folded filename*0= etc.
                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 26 Nov 2004 03:55:00 +0100

Bruce Lilly wrote:
 
> I know of a number of ISPs that block outbound port 25
> (SMTP) connections.

Actually a dubious idea, a zombie can still cause harm using
all other ports.  It's a solution of [censored] organizations
like Spamcast not willing to pay a working abuse management.

> I know of no ISPs that block outbound connections to port 80

It's about users reading their news while they are offline.

That's no UUCP trick, one user reported that he polls his news
during the night, and then reads and answers it on his laptop
on the way to resp. from his office (offline, in a train).  Of
course he could bookmark interesting links, but it's not the
same as online.
                Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 26 Nov 2004 14:20:35 +0000

Frank Ellermann wrote:

>zero or more of these constructs in Injection-Info.
>  
>
Exactly.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 26 Nov 2004 11:06:09 -0500

> >zero or more of these constructs in Injection-Info.

If one is going to use MIME-like parameters, that's exactly wrong;
one may not have multiple parameters with the same attribute name.
Syntax similar to that of a Received field, however, could
accommodate multiple instances (as is the case for the Received
field "with" component).

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 26 Nov 2004 11:58:24 GMT

>If we all just happen to magically agree, we can move on to more 

Indeed, but there are still several people whose position on some of the
options is not clear. I think the 4 options I gave still cover the viable
possibilities (though if people want to support Bruce's #5, #6, #7 or #8
then let them speak up). So far, only three people have ranked them in
order, and I think it would be helpful if more people did so.

Even when we have a front runner, there would still be details to fix up
(e.g. the names to be used, what to do about multiple addresses/URLs,
etc).

>>>As a chair I would note that I see no consensus to use mail-complaint-to 

I think the question is whether to provide both of them initially.

>Note, that this SHOULD belongs to USEAGE.

Which is where we disagree.

>And I am strictly against it becoming a MUST.

Indeed.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 26 Nov 2004 11:28:52 GMT

>I don't remember any successful attempt.

Indeed, but if the market is not pressing too hard in the direction you
don't want it to go, then it is folly to encourage it in that direction by
providing special features for it.

That is the beauty of doing it via Injection-Info. You give them
mail-copies-to as a parameter. Then, if the market really does want to go
the URL way, it will demand another parameter (or start using
x-url-complaints regardless). And at that point (if it happens), you add
it as an extension.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 26 Nov 2004 11:48:46 GMT

>argument(s) to choose one solution over another.

Also when, after a long discussion, it is not clear who is still
supporting what, especially if several new options have been introduced
along the way.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 26 Nov 2004 11:45:56 GMT

>But this is generally not an argument against URLs.

Our draft has always said that (MUST for injectors, SHOULD for some
others) that the mail addresses news@agent and usenet@agent are to be
available, in conformity with RFC 2142, plus abuse@agent for an agent
offering its services to the general public. That has been a long standing
tradition. Complaints-To and the like is really provided only for where
the site wants to use something other than 'abuse' (e.g. 'news-abuse' as
distinct from 'mail-abuse'), or where the MX record for its centralized
abuse department is different from the FQDN it puts in the Path header.

Incidentally, one of the advantages of a Complaints-To header over a
parameter of Injection-Info is that it would be suitable for use in
Emails, if the email community wants to use it.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Nov 2004 03:05:42 +0100

Bruce Lilly wrote:
 
> If one is going to use MIME-like parameters, that's exactly
> wrong; one may not have multiple parameters with the same
> attribute name.

Where does it say so ?  I really tried to check this before I
posted here (it's an "obvious" problem ;-) and found no rule
against it... within 5 minutes <gd&r>
                                       Bye,
Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Nov 2004 03:12:33 +0100

Charles Lindsey wrote:
  
> one of the advantages of a Complaints-To header over a
> parameter of Injection-Info is that it would be suitable
> for use in Emails, if the email community wants to use it.

Good point, but OTOH it's easier to get rid of _one_ bogus
Injection-Info than to check multiple headers for forgeries.

                       Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 26 Nov 2004 22:13:17 -0500

> against it... within 5 minutes <gd&r>

A moment's thought should convince you that given two
parameters with the same attribute name foo, you will
be unable to reassemble fragments:

  Content-Type: text/plain ; foo*0=x ; foo*2=z ; foo*0=a ;
    foo*1=y ; foo*2=c ; foo*1=b

Clearly that isn't practical, and the intent is certainly
that there can only be one parameter with a given
attribute name per field.

This was discussed not so long ago on the ietf-822
mailing list; see
http://www.imc.org/ietf-822/mail-archive/msg04115.html
for more.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Nov 2004 05:52:45 +0100

>     foo*1=y ; foo*2=c ; foo*1=b

Oops, RfC 2231 breaks MIME 1.0, it's not only obscure,
it's dead (for this version of MIME).

> Clearly that isn't practical

Yes.  Somehow they "forgot" to mention this "minor detail"
in RfC 2231.  But you caught them red-handed.

> http://www.imc.org/ietf-822/mail-archive/msg04115.html

The magic=on ; magic=off discussion, I recall it vaguely.

What next, submit a 2231bis with a new MIME version,
where all parameters must be unique per header-field ?

                     Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 27 Nov 2004 07:59:47 -0500

On Fri November 26 2004 23:52, Frank Ellermann wrote:

> Oops, RfC 2231 breaks MIME 1.0,

No, it's part of MIME; the first "word" in its title is "MIME".

> where all parameters must be unique per header-field ?

Ned said that he intends to revise the MIME documents,
and there are drafts of some parts. He has said that the
issue of uniqueness will be addressed.

A new MIME version number is unlikely.

---

From: [email-masked]
Date: Sat, 27 Nov 2004 11:08:55 -0800 (PST)

Indeed.

> issue of uniqueness will be addressed.

Yep. The intent was always that parameters be unique. Things that are obvious
to everyone involved at the time can sometimes slip through the cracks and not
get covered in the specification.

> A new MIME version number is unlikely.

Yes, well, we botched the versioning thing rather badly, so we're pretty
much stuck with 1.0 forever.

				Ned

P.S. If 2231 ever gets revised adding something along the lines of "SHOULD NOT
use these encodings unnecessarily" seems like a good idea too. Or maybe even
make it a MUST NOT...

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 02:55:27 +0100

Bruce Lilly wrote:
 
> it's part of MIME; the first "word" in its title is "MIME".

But the seventh word is "extensions", and your example showed
that some of these *-hacks are not compatible with non-unique
MIME 1.0 parameters.  It was added as an afterthoght, and it
doesn't work for this case.

> A new MIME version number is unlikely.

Removing the general *-folding could solve the problem, or
restricting it to parameters where it's explicitly allowed
and potentially necessary (e.g. filename= but not for URIs).

Something like boundary*= / boundary*0= / boundary*0*= could
be really dangerous, if it's (ab)used to bypass spam filters.

                        Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 03:34:47 +0100

[email-masked] wrote:

>> the first "word" in its title is "MIME".
> Indeed.

It's incompatible with non-unique parameters, it works only
for a proper subset of legal MIME - as far as it's implemented
correctly anywhere, I've heard that Opera tried this, and that
others try to use encoded words where it's definitely wrong.

>> the issue of uniqueness will be addressed.
> Yep. The intent was always that parameters be unique.

In the case discussed here non-unique parameters make sense.
Of course we could avoid it somehow, but it's more "KISS" with
zero or more complaints-url= parameters.

Same reasoning as in Martin's proposed Archived-At:, where he
came to the conclusion that one URI per Archived-At: is the
way to go (plus allowing more than one of these header fields).

> we botched the versioning thing rather badly, so we're pretty

Now here's a reason to move the worst *-hacks to a new version,
and then forget it for the next decades, until the whole world
uses Unicode filesystems, or whatever they'll do in 2050.

> If 2231 ever gets revised adding something along the lines of
> "SHOULD NOT use these encodings unnecessarily" seems like a
> good idea too. Or maybe even make it a MUST NOT...

You could make it a "MUST NOT ... unless explicitly allowed for
the affected parameter".  Bruce has demonstrated that it cannot
be allowed for non-unique parameters, and it would be an awful 
security loophole for boundary=

                      Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 27 Nov 2004 22:13:58 -0500

> doesn't work for this case.

There simply aren't any cases where a Content-Type or
Content-Disposition field needs multiple parameters with
the same attribute name.  There are cases where long
parameters need to be split to avoid problems. (And
there are cases where charset or language need to be
indicated).

> Removing the general *-folding could solve the problem

That's not going to do anything about the version
number problems.

> and potentially necessary (e.g. filename= but not for URIs).

URIs can be quite long; they're a good example of
why continuation parameters are useful (and the
continuation example in RFC 2231 *is* a URI).

And charset and language tags will also be necessary
for the IRI crowd.

> be really dangerous, if it's (ab)used to bypass spam filters.

Sorry, no.  Any process that needs to examine MIME
body parts needs to do so properly, and that includes
handling RFC 2231 continuation parameters.  Vendors
who cut corners by half-assed approaches to MIME
messages have already caused problems:

http://www.kb.cert.org/vuls/id/836088

And that's (well) after RFC 1344 specifically mentioned
gateway issues related to MIME.

---

From: Bruce Lilly <[email-masked]>
Date: Sat, 27 Nov 2004 22:38:09 -0500

> Now here's a reason to move the worst *-hacks to a new version,

You seem to have missed the point; there almost certainly
won't be a new version; among the issues preventing it
are:

1. There is no provision for a MIME 1.0-compliant product
    when it encounters a different MIME-version; what should
    it do? Revert to non-MIME handling of messages?  If not,
    which specific MIME 1.0 constructs should be handled
    differently by such a product in those circumstances?

2. The semantics for MIME-Version numbers are unclear;
    RFC 2045 merely says that there are two integer fields:
    is "001.000" equivalent to "1.0" (leading zeroes)?

3. What happens when versions are mixed in the same
    message (e.g. nested message types, multipart types)?
    MIME-Version fields are only valid at the top-level
    message header and in encapsulated message type
    headers.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 05:48:28 +0100

Bruce Lilly wrote:

> the same attribute name.

Yes.  But we're talking about an URL in Injection-Info here,
or other cases where more than one value could make sense.

Or do you propose to ignore 2231 in these cases, because
it's irrelevant for anything not starting with Content-*: ?

> indicated

Let's say "can be", because it doesn't work well for the
filename= case depending on the native filesystem.

I've found a way to generate Latin-1 filenames on my HPFS,
which causes a nice dead loop when I change the codepage
back to 850.  Okay, it's broken and I own the pieces, but
something like a universal concept of filename simply does
not exist yet.

> URIs can be quite long; they're a good example of why
> continuation parameters are useful (and the continuation
> example in RFC 2231 *is* a URI).

They don't have embedded WS, therefore the simple rule to
insert resp. remove FWS is much better than the *-hack for
URLs.  I trust that some implementations get FWS folding
right, but I don't believe in the *-hack:

url*1*=mozilla; what=ever; url*0*=us-ascii'en-GB-OED'"about:";

Who's supposed to get this right ?  If it's correct, of course
you can't create it in this order, but apparently you should
accept it.  Or what about a relatively harmless

bad*0*=us-ascii'en-GB-OED'"about:"; bad*1=mozilla;
url*0*=us-ascii'en-GB-OED'"about:"; url*1*=mozilla;

Apparently only the latter is allowed.  I'd simply refuse to
implement it, it goes against all my professional instincts.

I really love MIME, it's the best standard I know (okay, that
collection is somewhat limited, but I'd need more than hands
and feet ;-)  The RfC 2231 *-hacks really destroy that beauty.

> And charset and language tags will also be necessary for the
> IRI crowd.

Not that I'm aware of, it's IDN for servers and percent-encoded
UTF-8 for anything else.  Sure, the language tags make sense,
chapters 4 and 5 (minus 4.1) in RfC 2231 are fine, or at least
tolerable.  But the folding rules are not.  Fortunately they
are unnecessary for URLs.

> Sorry, no.  Any process that needs to examine MIME body parts
> needs to do so properly, and that includes handling RFC 2231
> continuation parameters.

IBTD.  The proper way is to ignore RfC 2231, and treat anything
trying to use it for folding as spam.  You cannot mess around
with a MIME boundary=, it's the same madness like NO-WS-CTL in
a Message-ID.  Protocols ought to be robust.

> Vendors who cut corners by half-assed approaches to MIME

It's not the implementors who caused these problems, but the
authors of RfCs like 2231 and 2184.  You just don't break any
conforming implementations by adding "extensions" later, that's
why there is a version number.

It's a PITA, I can see it for the "1" in v=spf1, but it won't
go away by pretending that the whole world "upgrades" their
perfectly working software.

> http://www.kb.cert.org/vuls/id/836088

Quotes:  'Block "message/partial" MIME Types'
         'Disable Message Reassembly'

That's essentially the same line I used against the *-hacks.

Please note that I'm not one of the majority shooting any MIME
multipart on sight.  Quite the contrary, I like MIME.  But some
of its "features" aren't "KISS", and that's the precise moment
when it breaks sooner or later, if too many users get it wrong
or abuse it.

> gateway issues related to MIME.

Yes. it's an old problem, some nets limited the mail size, and
that's probably still an issue in binary newsgroups, as far as
they don't use yenc :-|

Content-Conversion is interesting, it's apparently not listed
in draft-klyne-hdrreg-mail-05.txt
                                   Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 06:27:18 +0100

Bruce Lilly wrote:
 
> You seem to have missed the point

No.  My point was that moving the incompatible *-hacks to a
new MIME version kills them for good for this century.

> There is no provision for a MIME 1.0-compliant product
> it do? Revert to non-MIME handling of messages?

Sure, what else.  Garbage in, garbage out.

> The semantics for MIME-Version numbers are unclear

What is unclear about "verbatim text", as defined in RfC 1521,
especially marked as clarification of 1341 ?  If "2.0" has a
problem with "02.0" or "2.00", then it can say so.  But "1.0"
is the one and only format for "1.0".

> What happens when versions are mixed in the same

Let "2.0" solve its own problems, for "1.0" it's irrelevant.

                        Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Nov 2004 08:05:28 -0500

> or other cases where more than one value could make sense.

There is still the fact that parameter order is insignificant,
whereas in the case of multiple URIs with different
schemes, there is almost certainly a preference hierarchy.
RFC 2369 handles that by having most preferred first, and
uses a mechanism where order can be defined as significant.

> it's irrelevant for anything not starting with Content-*: ?

Trying to graft MIME parameters onto a non-MIME field
is the problem.  It's a problem for implementors, and
it's a problem for instances like this.  It's also unnecessary,
as there are other extensible ways of handling name/value
pairs in message header trace fields.

> something like a universal concept of filename simply does

Any suggested filename that includes octets outside of
the common part of ANSI X3.4/ISO-8859/ISO-10646 requires
encoding, and interpretation of encoded content by the
recipient requires an indication of the charset. Likewise for
charsets which do not share such a common subset, such
as EBCDIC.
 
> URLs.

Yes, such a scheme can be made to work for URIs as an
isolated case. But at the protocol level that we're discussing,
we're not dealing exclusively with URIs; we're dealing with
name/value pairs.  Interpretation of such a pair as a URI
occurs at a different protocol level.  At *this* protocol
level, things need to be specified in a manner that works
for name/value pairs in general, not just for one isolated
case.

> implement it, it goes against all my professional instincts.

It's unclear what you intend; there are so many problems
with your examples:
1. you can't have double-quotes starting in the middle of
    a parameter value; you can quote the entire value,
    except for an extended-initial-value, where tspecials
    and certain other content must be encoded
2. there's no standard language tag "en-GB-OED";
    at minimum the third component is going to be
    implementation-dependent
3. if you're trying to convey a URI, there is no standard
    scheme named "about"
4. foo*1*=bar and foo*1=bar are equivalent (but
    foo*1*=b%61r and foo*1=b%61r are not. Since
    your last pair of examples differs only in attribute
    name and trailing asterisk in an extended-other-name
    whose corresponding value consists entirely of (legal)
    attribute-chars, it's not clear why you seem to think
    there is a problem related to those issues (in fact
    both lines have problems because of the preceding three
    issues affecting the first parameters in each line).

> and feet ;-)  The RfC 2231 *-hacks really destroy that beauty.

That's one opinion; 2231 extensions provide necessary features
in a backwards-compatible manner.  As MIME itself provded
necessary features in a backwards-compatible manner.  Or
would you prefer to return to the simple beauty of plain text
only in a subset of ANSI X3.4?
 
> UTF-8 for anything else.

Any charset other than the default, including utf-8, needs to
be indicated with an appropriate charset tag; otherwise there's
no way to know *which* non-default charset is being represented
by the encoding.

> IBTD.  The proper way is to ignore RfC 2231,

"Proper way" for *what*?  If you're trying to parse a message's
Content-Type or Content-Disposition field's parameters, RFC 2231
has to be taken into account -- it is an amendment to the MIME
specification which has gone through the IETF process (including
consultation with developers).

> and treat anything 
> trying to use it for folding as spam.

You can treat all messages as spam if you like; for many people
that would result in fewer errors than treating no messages as
spam.  Most people would be dissatisfied by either extreme
approach.

> You cannot mess around 

Both protocols are robust as designed; there are, however,
plenty of shoddy implementations to point fingers at. MIME
multipart boundary delimiters can contain spaces, and may
be as long as 70 octets (unencoded, and excluding the
double hyphens).  They may also contain other characters
which would have to be encoded or placed in a quoted
parameter value.  "Boundary" is eight octets.  Syntactic
glue adds more length, which may exceed what SHOULD
be permitted as the maximum line length.  Splitting a long
boundary parameter to kep lines within the recommended
maximum length is a perfectly reasonable thing to do.  In
the case of a boundary value containing space characters
(e.g. "Next part"), encoding each space character as %20
(which adds length) to avoid breakage by shoddy
implementations of transport agents and gateways is also
perfectly reasonable.
 
> why there is a version number.

In the specific instance cited, it is absolutely poor vendor
implementations (ignoring RFC 1344) that caused problems.
The authors of RFCs 2184 and 231 are also authors of the
core MIME RFCs.  RFCs 2045-2049 are dated November 1996;
2184 is dated August 1997 and 2231 is dated November 1997.
Yes, that's "later", but not by much, and was done with
community input and review.  You still seem to have some
trouble understanding the problems associated with MIME
version numbering...

> That's essentially the same line I used against the *-hacks.

That's the approach taken by some vendors. "Throw the
baby out with the bath water" is *an* approach.  Neither
is useful.
 
> Yes. it's an old problem, some nets limited the mail size

It's an issue that isn't going to go away. 20 seconds of
high-definition video (at 1.5 Gb/s) is 3.75 GB.  I suspect
that you'd have a hard time sending that in one chunk.

> in draft-klyne-hdrreg-mail-05.txt

It was a dead end, never standardized; RFC 3297
specifies a mechanism which can accommodate the
desires of both sender and recipient.

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Nov 2004 08:19:14 -0500

> new MIME version kills them for good for this century.

You have missed the point; RFC 2231 is part of MIME 1.0.
You're 7 1/2 years too late (and even then, it would have
been unlikely to have had a different MIME version).

You can try to convince others that a different version
which removes the continuation feature should be
established, but that's probably a losing proposition.

> Sure, what else.  Garbage in, garbage out.

Well, if you really feel so strongly that a new version
which removes parameter continuation, but is otherwise
the same as MIME 1.0 is desirable, go ahead and
propose it.  Bear in mind that that means that for all
practical purposes, you'll be limited to sending plain
text in ANSI X3.4 for the foreseeable future, since that's
what "non-MIME handling" entails.
 
> is the one and only format for "1.0".

None of the specific examples in RFC 2045 are verbatim
"1.0" due to CFWS.

> Let "2.0" solve its own problems, for "1.0" it's irrelevant.

Well, I guess we'll leave it to you to work out in your
proposal for 2.0 which excludes 1.0's parameter
continuation.

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 22:16:18 +0100

> There is still the fact that parameter order is

Alexey wanted multiple URLs, he didn't say "ordered list".

> there is almost certainly a preference hierarchy.

My uninformed interpretation of...

| List-Unsubscribe:
|     <https://www1.ietf.org/mailman/listinfo/asrg>,
|     <mailto:[email-masked]?subject=unsubscribe>

...would be "pick what you like".

> RFC 2369 handles that by having most preferred first

Yes, they say so.  But IMHO my personal preferences as a human
user are more important.

> is the problem.

Okay, so what do you want ?  Injection-Info is no Content-*,
can we do whatever pleases us and simply have zero or more
complaint-url="URL" with the natural FWS folding ?

> encoding

If you extract the common octets from the mentioned standards
you'd probably get 0..159, that's already too much for all
installed filesystems on my box.  And it fails for UTF-8, but
0..127 isn't much better.

 [FWS allows to fold long URLs] 
> isolated case. But at the protocol level that we're
> discussing, we're not dealing exclusively with URIs; we're
> dealing with name/value pairs.

Are you saying that RfC 2017 got it wrong ?  Is that a matter
of the "URL" delimiter, and the <URL> in RfC 2369 fixes it ?
They simply say "internal whitespace being ignored" in 2369.

> It's unclear what you intend

I intended to screw up about:mozilla beyond recognition using
the *-hacks of RfC 2231.

> you can't have double-quotes starting in the middle of a
> parameter value

Fixing that I get url*0*=us-ascii'en-GB-OED'about%3A;
 
> there's no standard language tag "en-GB-OED"

Then let's say url*0*=us-ascii'en-GB-oed'about%3A;
or just for fun url*0*=us-ascii'i-klingon'about%3A;

> there is no standard scheme named "about"

Yes, let's use dict://dict.org/d: instead of about:
url*0*=us-ascii'i-klingon'dict%3A%2F%2Fdict.org%2Fd%3A

 [bad*0* and bad*1 vs. url*0* and url*1*]
> it's not clear why you seem to think there is a problem
> related to those issues

The problem was a hallucination on my side, I didn't see the
clear title*2="isn't it!" example in 4.1.  So now we have...

url*1=mozilla; what=ever;
url*0*=us-ascii'i-klingon'dict%3A%2F%2Fdict.org%2Fd%3A

...and still the question "who's supposed to get this right ?"

>> The RfC 2231 *-hacks really destroy that beauty.
 
> That's one opinion; 2231 extensions provide necessary
> features in a backwards-compatible manner.

Minus the problem with multiple parameters, and ignoring the
side-effects of using it where some old (resp. simple) MIME
implementations don't expect it (as in boundary=)

> only in a subset of ANSI X3.4?

Not when I need a multipart/digest in an abuse complaint. ;-)

Of course some abuse desks still insist on plain/text, because
a script deleting the Content-Type in the main headers on their
side if they don't like it would be asking too much. :-(

> RFC 2231 has to be taken into account -- it is an amendment
> to the MIME specification which has gone through the IETF
> process (including consultation with developers).

It can be still incompatible resp. a PITA, and some ideas just
don't fly.
 
> Splitting a long boundary parameter to keep lines within the
> recommended maximum length is a perfectly reasonable thing to
> do.

Our definitions of "perfectly reasonable" are different, in my
definition there's a "if it can cause harm just don't do it".

> Yes, that's "later", but not by much

2045 is based on 1521 (September 1993) resp. 1341 (June 1992),
and 5 years are IMHO too much to introduce "extensions" which
turn out to be incompatibilities.  In the case of v=spf1 "we"
(a "tinw" known as SPF community) have a problem with 6 months.

 [message/partial] 
> that you'd have a hard time sending that in one chunk.

Yes, it's more than my entire harddisk space.  You could try
an external body with HTTP/1.1 chunking if you insist on it,
for message/partial you'd better check the routing before. 

 [RfC 1344, Content-Conversion]
> It was a dead end, never standardized

The future 3864 registry apparently allows status "historic",
the RfC editor page claims status "informational" for RfC 1344.

                    Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 22:52:19 +0100

> You have missed the point; RFC 2231 is part of MIME 1.0.

It can't if it's incompatible.  You have shown this with:

| Content-Type: text/plain ; foo*0=x ; foo*2=z ; foo*0=a ;
|     foo*1=y ; foo*2=c ; foo*1=b

> You're 7 1/2 years too late

First of all you found this incompatibility, I missed it,
and then it's never too late to find and fix a bug.

> established, but that's probably a losing proposition.

Quite the contrary, it would be the new MIME version which
adds this incompatible restriction as a side-effect of the
continuation "feature" (= feature in MIME 2.0, bug in 1.0)

> None of the specific examples in RFC 2045 are verbatim

| Messages composed in accordance with this document MUST
| include such a header field, with the following verbatim
| text:
|     MIME-Version: 1.0
[...]
| NOTE TO IMPLEMENTORS:  When checking MIME-Version values any
| RFC 822 comment strings that are present must be ignored.

Sorry, I still don't see any problem with this specification.

> we'll leave it to you to work out in your proposal for 2.0
> which excludes 1.0's parameter continuation.

I'm not planning a new version.  MIME "1.0" ends with RfC 2049,
because RfC 2231 would be incompatible, and you're the crown
witness.  I'm only a member of the star chamber ;-)  Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Nov 2004 08:47:50 -0500

> |     foo*1=y ; foo*2=c ; foo*1=b

Since there cannot be multiple instances of the same attribute
in the same field due to other considerations, it's not
incompatible.
 
> and then it's never too late to find and fix a bug.

Apparently the issue of attribute uniqueness (which, as
noted above is not an incompatibility) has long been
known, but hasn't been publicly documented in the
applicable standards yet.  I chose to present that as
an example of why one cannot have multiple instances
of the same attribute name because it's easy to
comprehend w.r.t. the specific discussion taking place
here; as noted it's not the sole factor which prevents
multiple instances of an attribute name.
 
> continuation "feature" (= feature in MIME 2.0, bug in 1.0)

As mentioned, RFC 2231 is already part of MIME 1.0, and
has been for quite some time. It's not a "bug". It's
incorporated in a variety of products, and an attempt to
remove it would be an incompatible change at this point --
it would break existing implementations which comply
with Standards Track protocol.
 
> Sorry, I still don't see any problem with this specification.

Pretty much a moot point since a new version is unlikely.
 
> because RfC 2231 would be incompatible

No.  RFC 2231 is intentionally compatible, and specifically
amends RFCs 2045 and 2047.

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Nov 2004 09:31:14 -0500

> complaint-url="URL" with the natural FWS folding ?

We could, provided we provide a clear and complete specification.
We should consider liklihood of implementation.  It has been
claimed (unconvincingly) that because there may exist parsing
of MIME parameters for Content-Type and Content-Disposition
fields in some software, parsing of such parameters in other
fields will magically happen as well.  More likely parsing would
be botched or such new fields would simply be ignored by
many developers.  We could devise some mechanism which is
not used anywhere else, possibly with similar results. Or we
could use something comparable to what is used in existing
message fields and which is relatively simple to parse.  It
depends on what we really want to achieve; do we want to
specify something that will have a chance of being implemented
correctly, or do we want to devise a complex scheme to show
that we can write a complex specification?

> 0..127 isn't much better.

ANSI X3.4 is limited to 0-127 and in practice there are values
within that range that require encoding.
 
> Are you saying that RfC 2017 got it wrong ?

No, RFC 2017 deals exclusively with URIs in a subset of a
single case (URIs with media type message/external body)
in a single field (Content-Type). We're not discussing that
field or media type or message body access mechanism.
 
> Is that a matter 

RFC 2369 handles URIs (per RFC 1738 syntax, compatible
with 2396 syntax), but is incompletely specified (no ABNF!).
If we wish to use multiple URIs in a separate field similar to
the List- fields described in RFC 2369, we could use that
mechanism, but we should completely specify it including
ABNF.  That's complicated by incompatible changes in the
URI syntax draft which will probably be approved before
we get around to a specification.

> They simply say "internal whitespace being ignored" in 2369.

RFC 2369 also says "MUST NOT insert whitespace within the
brackets".  Ignoring whitespace when parsing is apparently
intended to cope with mangling during transit, not as a
mechanism for deliberately folding long URIs when generating
a field.  RFC 2369 completely ignores (the common case of)
long URIs.

> ...and still the question "who's supposed to get this right ?"

You really should be using the registered language tag "tlh"
instead of the deprecated "i-klingon". Aside from that nit, I
get two parameters:

what=ever
url=dict://dict.org/d:mozilla
 
> Minus the problem with multiple parameters,

That issue was always present, and as noted in the ietf-822
discussion, the only reasonable conclusion is that multiple
instances of parameters with the same attribute name in a
single field are not permitted -- completely independently of
parameter continuation issues.

> and ignoring the 

As I said, there are plenty of shoddy implementations to
point fingers at.  Users of old software can use metamail
to handle MIME.
 
> Not when I need a multipart/digest in an abuse complaint. ;-)

Why do you think you *need* multipart/digest?
 
> It can be still incompatible resp. a PITA, and some ideas just

RFC 2231 has been around for seven years and has multiple
interoperable implementations.
  
> definition there's a "if it can cause harm just don't do it".

Splitting long parameters when generating *avoids* harm
caused by improper folding in transit.
 
> (a "tinw" known as SPF community) have a problem with 6 months.

RFC 2231 is already on the Standards Track.  Too late now to
try to derail it.
 
> the RfC editor page claims status "informational" for RfC 1344.

"Historic" status is generally used for something that was at
one time standardized but has become obsolete or is otherwise
deprecated; Content-Conversion was never standardized.
RFC 1344 is still active as an informational RFC (N.B. it doesn't
purport to standardize a Content-Conversion field; it merely
suggests that one might be standardized -- that never happened).
Much of it is effectively obsolete due to subsequent activity, but
the parts about message/partial and gateways are still applicable,
and the point is that vendors who ignore proper handling of
MIME (as has been the case with some products as noted in the
CERT vulnerability note previously linked) place their users at risk.

---

From: [email-masked] (Claus Färber)
Date: 30 Nov 2004 20:57:00 +0100

Bruce Lilly <[email-masked]> schrieb/wrote:
> You are wrong; the syntax is very close and may pose problems for some
> types of parsers.  If you really thought the syntax was easily

Well, it *is* possible. Absolute(!) URIs start with "<scheme>:" (i.e.  
/^[a-z][a-z0-9+\.-]+:/ as a regexp) while email addresses can't have an  
unquoted ":". But it's far less roboust than just using mailto URIs;  
implementor's *will* get it wrong.

Claus
-- 
http://www.faerber.muc.de

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Nov 2004 15:26:09 -0500

On Tue November 30 2004 14:57, Claus Färber wrote:
> unquoted ":".

No,

mailto:[email-masked];

is a legal address (N.B. that is *NOT* a mailto URI!).  Note that
"address" encompasses named groups (as above) as well as
single mailboxes.

> But it's far less roboust than just using mailto URIs;   

Now an address such as the above is terminated with a semicolon,
whereas a mailto URI is not.  Semicolons may appear in URIs,
however, so a simple RE (which in any event isn't a parser per se) is
unlikely to suffice.  In any event, there are parsers with limited
look-ahead capability that will have problems with determining
whether something is a URI or and address.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Dec 2004 01:00:12 +0100

Bruce Lilly wrote:

>> can we do whatever pleases us and simply have zero or
>> more complaint-url="URL" with the natural FWS folding ?
 
> We could, provided we provide a clear and complete

Now that's good news.  We have a proposed syntax allowing
[FWS] within the URL, anyhthing else should be also simple.

> You really should be using the registered language tag 
> "tlh" instead of the deprecated "i-klingon".

IIRC it's not yet deprecated, the stuff about tags is still
only a draft.  The last time I read it they tried to use an
obsolete version of ISO 3166 (minus CS problem), and their
en-GB-scouse (or similar) matched en but not en-scouse.

A better example, de-CH-1996 should match either de-1996
(= "new orthography") or de-CH (= "no szlig") before de.

> url=dict://dict.org/d:mozilla

Yes, you got it right, but it's still a pain to implement
it in simple user agents.  Same problem as in your remark:

| do we want to specify something that will have a chance
| of being implemented correctly
  
> Why do you think you *need* multipart/digest?

It's convenient if I want to send multiple related mails
to a single service like abuse@ or SpamCop.  And it's in
the list of RfC 2049 (minimal MIME conformance).

> RFC 2231 is already on the Standards Track.  Too late
> now to try to derail it.

IMHO it is "derailed", you found a serious problem in it,
not only one of the typos listed as "errata".  Maybe they
can fix it somehow, add a "MUST be unique" to MIME, and a
"MUST NOT be used for simple parameters like boundary" to
the wannabe-extension.
                      Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Dec 2004 01:27:34 +0100

Bruce Lilly wrote:

> Since there cannot be multiple instances of the same
> attribute in the same field due to other considerations,
> it's not incompatible.

What "other considerations" ?  The author saying that he
had something like an environment in mind explains why he
forgot to mention it explicitly.  But we've already seen
that it could make sense, e.g. if I'd say...

charset=windows-1252 ; charset=iso-8859-1

...it could stand for "I didn't use any 128..159, it works
with whatever you have, and if you really insist on it I'm
ready to accept replies with windows-1252".

Something else I've seen in real spam was another case of
magic=off ; magic=on ; magic=off

Three Content-* headers with name=spam.htm (1st and 3rd)
and name=evil.exe (2nd) trying to trigger filters based on
the long list of WIN executable names.  IIRC that confused
SpamCop, SC doesn't allow to report mail worms as spam.

> RFC 2231 is intentionally compatible, and specifically

IBTD and recommend to avoid it like hell until the authors
fix the many problems with it somehow.

                           Bye, Frank

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Nov 2004 20:17:04 -0500

On Tue November 30 2004 19:27, Frank Ellermann wrote:
> What "other considerations" ?

Insignificance of order, as Ned explained in the ietf-822
message that I cited earlier.

> fix the many problems with it somehow.

Are you referring to something other than the published
errata?

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 30 Nov 2004 20:31:39 -0500

> IIRC it's not yet deprecated,

According to my local copy of the official language-tags document:

i-klingon    Klingon                                 [Everson]   Deprecated use ISO
                                                                 639-2 tlh, registered
                                                                                                                                 Feb. 24, 2004.

[Don't blame me for the weird indentation]

> it in simple user agents.

Here's the complete code change necessary to print the
parameters:

*** hooktest.c  Tue Nov 30 09:56:57 2004
--- franktest.c Tue Nov 30 08:12:39 2004
***************
*** 178,186 ****
              fprintf(stderr, "%d: ", child);
          print_token(stderr, 0, fld->tokens, 0);
          pmt(": ", fld->entity, 0, 0);
!         if (parameter_list)
              print_tokens(stderr, 0, parameter_list, 0);
!         else
              fputs("\r\n", stderr);
      } else
          hooks(fld, type, 0);    /* RFC 2049 */
--- 178,200 ----
              fprintf(stderr, "%d: ", child);
          print_token(stderr, 0, fld->tokens, 0);
          pmt(": ", fld->entity, 0, 0);
!         if (parameter_list) {
!             struct token *t;
!             struct list *l;
!             struct parameter *p;
!             char buf[1024];
!
              print_tokens(stderr, 0, parameter_list, 0);
!             for (t = parameter_list, l = t? t->list->head->list: 0; l ; t = l->element, l = t? t->list: 0) {
!                 p = t->parameter;
!                 if (p && p->attribute) {
!                     buf[0] = '\0';
!                     get_parameter(fld->entity->message, parameter_list, p->attribute->tok, buf, sizeof(buf), 0);
!                     if (buf[0])
!                         printf("%s=%s\n", p->attribute->tok, buf);
!                 }
!             }
!         } else
              fputs("\r\n", stderr);
      } else
          hooks(fld, type, 0);    /* RFC 2049 */

I simply did:

print "Content-Type: text/plain ; url*1=mozilla; what=ever; url*0*=us-ascii'i-klingon'dict%3A%2F%2Fdict.org%2Fd%3A\r" | ./franktest -a

and pasted the appropriate parts of the results into this
morning's message.  The entire process from reading
your message to composing a response with the result
took only a few minutes. Implementation in UAs
is not difficult given the right set of tools [adding the
capability for new fields in existing UAs is a horse of a
different color].

> the list of RfC 2049 (minimal MIME conformance).

convenience (for one party) != need.  Perhaps the
recipient finds it inconvenient to handle multiple
messages packaged in a digest (ISPs often wish to
add a tracking identification tag to each individual
message).