Subject: Polll results on injection-info, and some thought on progress

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 05 Sep 2005 02:54:49 +0200

OK, here's our result on injection-info.
A total of 3 people answered. Possible conclusions:

- The rest doesn't really care about this bit
- The group is tired and doesn't want to form more opinions

I can certainly believe tiredness. I did not make the timeline I suggested, 
and have severely underestimated the amount of time and energy it takes me 
to get even proposed closure on issues.
In terms of value for energy spent, closing the group may be a better 
alternative.

But I'll make one more round of trying to close things.

On this poll, the results are:

1) SHOULD THERE BE SUBSTANTIAL CHANGES TO INJECTION-INFO?
  1a) No, we should keep approximately the current syntax
      Charles Lindsey
  1b) Yes, we should pick a substantially different solution
      Frank Ellermann
  1c) None of the above

  No consensus.

2) IF SUBSTANTIAL CHANGES ARE MADE, WHAT FORM SHOULD IT BE?
  2a) Multiple header fields
  2b) A single header field with a syntax different from
      the "name=value" syntax
      Frank Ellermann, Charles Lindsey, Russ Allbery

  Perfect consensus.

3) IF THE SYNTAX IS KEPT, HOW SHOULD WE DESCRIBE IT?
  3a) Keep the current definition; it's good enough.
  3b) Specify ABNF for a "name=value" list, don't refer to
      "parameter"
  3c) Use the "parameter" definition, but add a non-normative
      description in modern ABNF
  3d) Use the "parameter", give an ABNF for each parameter
      value we define, but don't add an overall ABNF
      Charles Lindsey (with comments)
  3e) Something else
      Russ Allbery (fix the problem upstream, not here)

  No consensus.

4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
  4a) Yes
      Charles Lindsey, Russ Allbery
  4b) No
  4c) Something else
      Frank Ellermann (langtags in encoded-words only)

  A tendency towards "yes".

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 05 Sep 2005 06:40:36 +0200

Harald Tveit Alvestrand wrote:

> I can certainly believe tiredness.

Yes.  Actually I started to miss your weekly "open ticket"
summary, and considered to create / post a new version, but
Charles said he's away for some days, therefore I picked
something else on my "todo" list (2821bis ABNF).

> In terms of value for energy spent, closing the group may
> be a better alternative.

While that's an option I'd hate it if the Injection-Info

> 1b) Yes, we should pick a substantially different solution
[...]
>   No consensus.

That's a strange result, I wanted to support Bruce's idea.

Without the proponent (Bruce) that makes no sense.  Unlike
the Message-ID syntax I don't have any "different solution"
for Injection-Info (or rather my own proposal didn't work
as expected).

Bruce and Charles claim to have something that works.  If
Bruce isn't interested anymore to work out the details I'm
forced to withdraw my "1B".  What you then get is Charles
for "1A", whatever that is, at least it's not "no consensus".

>   Perfect consensus.

If we'd follow Bruce's idea, we'll follow Bruce's idea ;-)
For a "perfect consensus" I miss at least Bruce here.

The weird Injection-Info shouldn't be the reason to close
the WG.  Compared with <id-domain> vs. <id-right> it's
not relevant enough, above all it's new, we could also
move it to a separate document (even "experimental").

That is an excessively cowardly idea, but if the WG fails
after what - six (?) - years that should be for a solid
reason like "2822 considered too broad for news by some
but not all", not "2231 considered too gibbous for news".

                        Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 05 Sep 2005 07:53:11 +0200

[...]
> Actually I started to miss your weekly "open ticket"
> summary, and considered to create / post a new version

It's apparently down again, only the http-intro works
from my POV <http://rt.psg.com> - not the https pages.

Ticket states as I remember them:

#1046 2822/2231 MIME security considerations was "text
needed" but could be "text proposed". 

????? date-ABNF:  typo in 3.1.2, s/from/orig-date/

????? Path:  Use Harald's idea "name required" to get
rid of IP problems (BTW, 2821bis proposes HELO FQDN,
plus SHOULD NOT <address-literal> crap only for EHLO)

????? Path:  Finish the "diagnostic" syntax, and for
perfectionists maybe split FQDN (dots, toplabel, no
underscore) from name (no dots, underscores are okay) 

????? Message-ID:  last state 3:3:1 for <id-right> vs.
<id-domain> vs. 2822-is-fine (= Bruce).  That's 6:1
if the production names are ignored.

????? Differences from 1036:  use texts as posted in
the corresponding thread.

#1101 empty body: no support, one proposal to reject

#1102 terminology: use UA vs. server in USEFOR (Russ
didn't like it, but it's a minor editorial point, no
showstopper)

----- (no ticket):  Ask Henry to publish s-o-1036 as
FYI (or directly as historic like 4156 and 4167 - the
latter strategy might need a "last call", unclear)

Anything else excl. the known Injection-Info issue ?

                        Bye, Frank

#1101: http://permalink.gmane.org/gmane.ietf.usenet.format/29979 
#1046: http://permalink.gmane.org/gmane.ietf.usenet.format/29552

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 5 Sep 2005 19:01:25 GMT

>  No consensus.

The usual practice in that case is that the status quo remains. I.e. we
retain what we currently have (modulo further tuning).

>  3b) Specify ABNF for a "name=3Dvalue" list, don't refer to
>      "parameter"

>  No consensus.

Well at least we have eliminated 3a, 3b and 3c. I.e. there is a problem
with the present description that needs to be fixed.

But I have not seen Russ's comment (was it posted here?). May we have some
explanation of what "fixing upstream" means?

>  A tendency towards "yes".

In which case we should be discussing whether we allow it, but make
discouraging noises (mainly about the multi-line stuff, and probably in a
NOTE).

-- 
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: Mon, 05 Sep 2005 18:36:02 -0700

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

> explanation of what "fixing upstream" means?

If we're going to use MIME, we should use MIME.  If the current MIME spec
is broken, well, mail client authors are coping, and news client authors
can cope too.  If it's really broken, it can get fixed in a revision of
the MIME specification, which we'd then pick up automatically.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 6 Sep 2005 16:57:54 GMT

>the MIME specification, which we'd then pick up automatically.

There is nothing particularly broken about current MIME. It is just a
little tricky to interface to it correctly. It has four properties that
are of relevance to the present problem.

1. The syntax of <parameter> and its components is written in RFC 822
style, so if you want to know whereabouts CFWS is allowed within it, you
need to understand the RFC 822 comment and folding rules. Since the rest
of our draft follows the RFC 2822 comment and folding style, there is need
for a NOTE (non-normative) to draw attention to this and to indicate
informally what the rule would look like in 2822 style.

2. MIME makes provision for the syntax of the relevant header fields to
include
	.... *( ";" parameter ) ....
with the understanding that any <parameter>s used therein should have been
defined by some standard or registered with IANA or whatever. There is
also a clear understanding that if any <parameter> not so
standardized/registered/whatever is seen, it is to be accepted and ignored
(thus if a future extension adds a new <parameter> to some header field,
then existing software is not broken - though it will not see the benefit
of the new feature). We want to retain that useful MIME feature.

3. There are rules for when the <value> on the RHS of a <parameter> MUST
take the form of a <quoted-string> rather than a <token>; however, if
you cannot (be bothered to) remember which characters are/aren't
<tspecial>s, then it never hurts to enclose them in "..." regardless. We
also want to retain that feature.

4. It is NOT customary to give an ABNF syntax for each particular
<parameter> you choose to define (look through RFC 2046 which defines lots
of <parameter>s for lots of media types without using any ABNF at all).
The benefit of that appreoach is that you are excused from worrying
about <quoted-string>s and CFWS and whatever else.

That is not to say that ABNF has no place in defining <parameter>s. For
example we could well say that one of the defined <parameter>s of the
Injection-Infor field is called "posting-host", and its <value> must
consist of some <dot-atom-text>, allowing you then to write

Injection-Info: news.stanford.edu; posting-host = zebra.standford.edu

or, alternatively,

Injection-Info: news.stanford.edu; posting-host = (this is a long
    folded comment) "zebra.standford.edu"

That is the approach I propose to take (see
http://www.imc.org/ietf-usefor/mail-archive/msg01964.html). Are you happy
with that approach, subject to tuning (there were a few suggestions in the
subsequent discussion that I need to incorporate)?

Here is how it tackles the issues raised above:

#1. Covered in a NOTE.
#2. Contains a syntax as indicated.
#3. Covered in a NOTE.
#4. I give a table of the <parameter>s we propose to define, showing what
you are allowed to put in each (with the aid of some ABNF as in my example
above, which was somewhat oversimplified).

There is also a further NOTE about the gibbousness of RFC 2231 which
can be retained, or omitted, or hacked about as people might like.