Subject: #1080 Injection-info - poll design?

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 15 Aug 2005 12:33:55 +0200

No, I'm not going to run a poll on this one yet.
First, I have to figure out what alternatives are on, near or off the 
table...

CURRENT: Section 3.2.14 specifies an ABNF for the field that includes a 
number of parameter definitions, in "name=value" format, and allows the 
"parameter" ABNF entry.
"parameter" is imported from 2045+2231, according to section 1.4.
This introduces some oddities, including ambiguity on whether or not spaces 
are allowed around the equal signs, and one RHS that isn't a "value" 
(posting-host contains :)

PROPOSALS I'VE HEARD

- Junk the current definition, go for multiple header fields

- Junk the current definition, go for a single Received:-like header field

- Remove the dependence on "parameter", specify all ABNF ourselves.
  Stop accepting 2231 constructs.

- As above, but continue accepting 2231 constructs

- Keep importing "parameter", but clarify what we think it means in
  modern ABNF. Sort out the ambiguities with the non-parameter pieces.

- Change the ABNF to just a parameter-list, and give a table of parameter
  attribute names with corresponding syntax for values, sidestepping the
  question of how "parameter" is represented in ABNF

First question: Is that a reasonable summary of the alternatives that have 
been proposed?

(I *think* that the 4 last pieces are a matter of changing how the syntax 
of the Injection-info parameter is described. The 2 first ones would be 
throwing out the existing Injection-info and starting over.)

                     Harald

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 15 Aug 2005 08:58:13 -0400

> PROPOSALS I'VE HEARD

When or if this becomes a poll, can it include examples and a summary of
what objections have been raised to each?  I think some of those options
should be removed based on valid objections.

One of Frank's concerns was that injection date needed to be easy
to find with simple parsing.  I believe that requiring it to be
first was proposed in conjunction with one of the schemes.  Perhaps
the poll taking should include gathering votes on the parsing of
injection date.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 15 Aug 2005 18:35:13 +0200

> PROPOSALS I'VE HEARD
[...]
> - Remove the dependence on "parameter", specify all ABNF
>   ourselves.  Stop accepting 2231 constructs.

That failed for a hypothetical x-filename.  Bruce's idea
also won't allow file names, but he never claimed that his
proposal allows to add this kind of "x-token".

If we'd want to be free to add almost anything 2231 would
be the way to go.  I think we don't need this flexibility.

> - Keep importing "parameter", but clarify what we think
>   it means in modern ABNF.

That's not trivial.  While I see no problem in redefining
the <msg-id>, because it's at the core of NetNews and we
found a minimal modification (modulo names reflecting the
semantics), I don't think that it's our job to mess with
the 2231-parameter syntax.

A non-normative clarification might be okay.  I changed my
mind about this:  For obvious reasons we're already forced
to mess with MESSFOR, let's not also mess with MIME.

Bruce has a kind of "unified message syntax" integrating
MIME, and it's IMHO difficult to get this right.  Maybe a
future WG could tackle it, "everything we always wanted to
fix in 2822 / MIME / USEFOR (adding yenc just for fun)".
[...]
 
> Is that a reasonable summary of the alternatives that 
> have been proposed?

Yes, but I think the two quoted alternatives were already
identified as less desirable.

> I *think* that the 4 last pieces are a matter of changing
> how the syntax of the Injection-info parameter is described.

Maybe the last could also work for Bruce's Received-concept.

> The 2 first ones would be throwing out the existing
> Injection-info and starting over.

I don't like the first idea (header field zoo), but OTOH if
we are not smart enough to find a good working combination
(or unable to agree on one, or need another year for it),
then we better pick a zoo of simple header fields.  After
all that's as it is today.
                             Bye, Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Aug 2005 17:58:56 +0100

> should be removed based on valid objections.

The suggestion seems sensible to me.

> the poll taking should include gathering votes on the parsing of

Harald has already indicated that the issue with Injection-Date is 
closed. Let's not reopen it.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Mon, 15 Aug 2005 13:06:43 -0400

> closed. Let's not reopen it.

Do you mean that closing (dropping) the header field Injection-Date means
omitting the injection date from the Injection-Info header field too?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Aug 2005 08:12:59 +0200

> omitting the injection date from the Injection-Info header field too?

Can't parse this, so I'll explain what I think the facts are instead.

What I meant was that in discussion of ticket #1048, which was closed with 
"No change needed", Frank suggested moving the injection-date into 
injection-info.
After discussion on the list, I decided that there was no strong support 
for doing this, and closed the ticket (which was originally about something 
else).

                        Harald

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 16 Aug 2005 20:13:18 -0400

On Mon August 15 2005 06:33, Harald Tveit Alvestrand wrote:
> are allowed around the equal signs,

That's not ambiguous. 2045 and 2231 are based on 822, and spaces (and tabs
and comments and line folding) are allowed on either side of the '='
[confirmed by correspondence with one of the RFC authors].

> and one RHS that isn't a "value"  

Problems with use of address-list have also been identified.
  
> - Junk the current definition, go for a single Received:-like header field

It would be more accurate to state that the current text *is* junk (i.e. has
many known technical problems), and that it is "the current definition" only
because it is a document editor's personal idea; other ideas have not been
included by the document editor, and the document editor has not withdrawn his
problematic proposal.

The above two items are not necessarily mutually exclusive; e.g. Complaints-To
could be used for a specific purpose enabling UA assistance in preparation of
complaint messages, while purely human readable trace information could be in
a separate field.
 
>   Stop accepting 2231 constructs.

I believe that Frank suggested that at one point but has subsequently
withdrawn that proposal.
 
> - As above, but continue accepting 2231 constructs

1. Good luck; it's not easy
2. section 1.6: "This document uses a cite by reference methodology, rather than
   repeating the contents of other standards, which could otherwise
   result in subtle differences and interoperability challenges."
 
>   modern ABNF. Sort out the ambiguities with the non-parameter pieces.

Not significantly different from the above.

>   question of how "parameter" is represented in ABNF

a) that won't help with issues like address-list containing possible encoded-words,
   comments, etc.
b) if the IESG is doing its job, that won't pass IESG muster as it will be an
   incomplete (viz. insufficient for interoperability) specification; it will
   certainly generate negative comments during IETF Last Call.
 
> First question: Is that a reasonable summary of the alternatives that have 

Modulo "spin", Frank's possibly retracted proposal, redundant (duplicate)
descriptions of the same thing,...

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 16 Aug 2005 20:40:30 -0400

On Mon August 15 2005 12:35, Frank Ellermann wrote:

> MIME, and it's IMHO difficult to get this right.

You may be conflating MIME encoded-words (RFC 2047 as amended by 2231
and errata) with MIME parameters (2045 as expected to eventually be
amended by a missing-in-action erratum-to-be and by 2231 and errata).
There is an ABNF grammar that incorporates a simplification of 2822
with the former, but it does not address the latter, which is orthogonal
to 2822.

> Maybe the last could also work for Bruce's Received-concept.

The last = "sidestepping [actual specification]" won't pass IETF
Last Call.
 
> all that's as it is today.

A good carpenter or other craftsman has a toolbox consisting of many
tools, each of which does one thing (or a very few things) well.  A
Swiss Army knife is convenient for emergency use (e.g. hacking a tree
limb into a splint to stabilize a broken bone), but is no substitute
for a craftsman's toolbox; it is not as efficient for any one use as
the corresponding dedicated craftsman's tool.  We should be crafting
a well-designed format and protocol, not hacking things together (or
encouraging such hacking (e.g. x- values).

The reason that there is a separate Injection-Date field is to serve
a particular purpose in a manner which is amenable to efficient
implementation (i.e. w/o having to handle all of the gory 2231
syntax).  Even though it's possible to avoid 2231 contortions and
still combine the injection timestamp with other information (as is
done with the Received field (a.k.a. time stamp line), in the case
of news protocols the injection timestamp is used automatically and
frequently, whereas the Received fields "are primarily intended for
humans tracing" information.  So, while I'm not opposed to combining
the time stamp with other information provided it can be parsed
easily and efficiently, I support the separate Injection-Date field
as that provides the simplest possible parsing and doesn't mix
protocol information with human-readable tracing trivia.

Or to return to your "zoo" analogy; I prefer animals with familiar
but distinct characteristics.  You are free to try to cross a cow with
a bird to get a flying cow, but personally I wouldn't want to be
underneath your critter when it's flying and defecating at the same
time.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 17 Aug 2005 08:02:47 +0200

Bruce Lilly wrote:
 
> You may be conflating MIME encoded-words
[...]
> with MIME parameters

Yes, your "unified ABNF" is about the former.

> The last = "sidestepping [actual specification]" won't pass
> IETF Last Call.

I don't see why that should be a problem.  A general syntax
for the list, either *( name "=" value ) or *( name value ),
the latter is the variant for your concept, a set of names,
name = "for" / "from" / "by" or similar for your concept, or
name = "posting-host" / etc.

Either value = quoted-string or what you propose.  Specific
syntax for various values:  from-value = id-domain etc.

In your variants #2 and #3 you have a general value-syntax.

> I support the separate Injection-Date field as that provides
> the simplest possible parsing and doesn't mix protocol
> information with human-readable tracing trivia.

Fine, so I don't need to say that we should reserve the right
to reopen the Injection-Date ticket if your concept (number 2
on Harald's list) is used for the rest of this zoo.

In the case of Harald's 1 another way to get a similar effect
would be to use Injection-* field names.  The purpose is to
get rid of the complete zoo for the obscure "re-injection":
Kill all old Injection-*, insert new Injection-*.  Bye, Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 17 Aug 2005 09:15:47 +0200

--On tirsdag, august 16, 2005 20:13:18 -0400 Bruce Lilly <[email-masked]> 
wrote:

>> This introduces some oddities, including ambiguity on whether or not
>> spaces  are allowed around the equal signs,
>

It's not ambiguous whether spaces are allowed around the equal signs in 
"parameter".

But if the ABNF as given was intended as modern ABNF, this:

   sender-param    =  "sender" "=" sender-value

doesn't allow spaces around the equal sign. I can't tell whether that was 
intentional or a mistake. If it's intentional, it's inconsistent with 
"parameter"; if it's a mistake, it needs fixing.

                      Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 17 Aug 2005 16:20:28 GMT

>- Junk the current definition, go for multiple header fields

That's the "header zoo". Lacks extensibility, separates related concepts
(information about the injection process), and provides no convenient
mechanism for the injecting admin to tailor his own.

>- Junk the current definition, go for a single Received:-like header field

See my response to Frank.

The remainder are just ways of improving the present text, which I think
all agree has problems as it stands.

>  Stop accepting 2231 constructs.

Actually, the I18N part of 2231 isn't too bad.

>  modern ABNF. Sort out the ambiguities with the non-parameter pieces.

Actually, this was the way it was done in the old draft-13 (the syntax
provided was not normative). It tackled the specification of the
individual parameters much as I have recently proposed, but with more
verbiage.

>  question of how "parameter" is represented in ABNF

That is what I propose (though with some NOTEs to point out how the
"sidestepped" issues should be appraoched). Note also that the discussion
threw up a few requests for changes (e.g. s/dot-atom/dot-atom-text/),
which are really orthogonal to fixing the descriptive method.

>First question: Is that a reasonable summary of the alternatives that have 

Yes, I think so.

>throwing out the existing Injection-info and starting over.)

Indeed so.

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