Subject: #1080 - Poll about "injection-info"

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 21 Aug 2005 19:21:00 +0200

After reading through the comments on my August 15 posting, I'm going to 
attempt a poll, concerning section 3.2.14 of USEFOR.
Note the way the questions are divided up; I expect people to have opinions 
at multiple levels, so that saying "I think we shouldn't change the syntax, 
but if we change it, we should go for alternative X" is something that you 
can say.

I'll summarize the poll results on or after Wednesday, August 25.

If you have no opinion on a question, please say so.

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

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

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
  3e) Something else

4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?
  4a) Yes
  4b) No
  4c) Something else

-----------------------------------------------------------
Notes to the poll, gleaned from discussion:

1:

As I understand it, this is revisiting a previous WG
decision to pursue the current definition. That's something that we should 
not do lightly.

3:

The current definition has some stuff to the right hand side of the equals 
sign that doesn't conform to "parameter". We should either change this or 
make a NOTE saying it's deliberate.

Redefining "parameter" properly may not be trivial. Alternative 3d) could 
have a NOTE saying such things as "allow CFWS around the equals sign"; not 
saying anything would leave the mess for implementors to sort out.

Note also that putting stuff which allows encoded-words (such as 
"address-list") inside quotes puts the encoded-words out of reach of 
2822-conformant decoders....

4:

- If any fields need internationalization or extended character sets, RFC 
2231 may be needed.
- Long field values (x-filename?) may need RFC 2231

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 22 Aug 2005 09:14:52 +0200

Harald Tveit Alvestrand wrote:

> 1b

With an option to return to what we have (1A) if some
unforeseen major obstacles show up.

> 2b

With an option to extract some Complaints-To (that's
not an unforeseen major obstacle, it's a known issue)
  
> 3

Pass.

> 4c

The 2231 part about language tags in encoded words is okay.
The parameter stuff is a headache (see also ticket #1046).

                       Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Aug 2005 13:56:16 GMT

>  1b) Yes, we should pick a substantially different solution

1a

2b

>      value we define, but don't add an overall ABNF

[not 3a, which is definitely erroneous].

3d (assuming it is what I suggested, namely a list of <parameter>s as in
RFC 2045, with an accompanying list of the attribute/value pairs that we
recognize, with ABNF for what goes inside the <value> as needed;
otherwise 3e).

>4) SHOULD THE FIELD ALLOW RFC 2231 CONSTRUCTS?

4a (possibly with a NOTE to discourage the multiline stuff).

But I might not object to 4b (assuming that means we just use what is in
2045).

But 4b leaves us without any I18N, so one might explicitly choose also to
allow encoded-words within quoted-strings within values (but not with much
hope that user agents would decode them, hence my 1st choice is 4a).

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