headers
Pete Resnick | 2 Jan 05:26
Favicon

Getting 2822 to Draft


So, for the new year I started thinking about getting 2822 to Draft. 
(Also, 3822 is coming up in the RFC numbers :-) ). I've gotten 
started on getting a new draft together. There are a small bunch of 
nits to fix; that I can handle. There's also an implementation report 
to write. On that I'd like to get some help.

The one possible big thing has to do with the ABNF in 2822. Out of 
either altruism or insanity, some time ago Bruce Lilly had written up 
changes to the ABNF in 2822 to do some cool things. On the plus side, 
it seems to get rid of all of the [C]FWS shift-reduce conflicts, and 
it is already done. On the minus side, I don't know anyone (myself 
included) who has gone over it with a fine tooth comb, it is a 
significant number of ABNF changes, and it therefore might recycle us 
at Proposed. I am open to suggestions on this.

Comments?

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 75 comments |
headers
Simon Josefsson | 2 Jan 13:34

Re: Getting 2822 to Draft


Pete Resnick <presnick <at> qualcomm.com> writes:

> Comments?

Would 2822bis obsolete 822 fully?  If so, I believe it should mention
what happened to the X- header prefix that was part of 822.  I don't
believe simply removing them without stating why is a good idea,
people can draw many different conclusions from that, which affect
real implementations.

Thanks,
Simon
Permalink | Reply | 65 comments |
headers
Keith Moore | 2 Jan 16:02
Picon

Re: Getting 2822 to Draft


> The one possible big thing has to do with the ABNF in 2822. Out of 
> either altruism or insanity, some time ago Bruce Lilly had written up 
> changes to the ABNF in 2822 to do some cool things. On the plus side, 
> it seems to get rid of all of the [C]FWS shift-reduce conflicts, and 
> it is already done. On the minus side, I don't know anyone (myself 
> included) who has gone over it with a fine tooth comb, it is a 
> significant number of ABNF changes, and it therefore might recycle us 
> at Proposed. I am open to suggestions on this.

if the new grammar accepted the same language as the old one, I'd 
consider it nothing more than a clarification of the spec, and a reset 
to Proposed would be unnecessary.

or if the only differences could be seen as minor bug fixes to the old 
grammar, I'd consider it a minor bug fix to the spec.

IMHO simplifying the grammar and getting rid of parsing conflicts would 
both be highly desirable improvements.  if it then becomes possible to 
feed the ABNF to a parser generator and generate a verifier for 2822 
messages, that's a huge win.

why not post the revised ABNF as an I-D so that others can go over it 
with a fine tooth comb?  or has this already been done, and I missed 
it?
Permalink | Reply | 5 comments |
headers
Keith Moore | 2 Jan 16:06
Picon

Re: Getting 2822 to Draft


> Would 2822bis obsolete 822 fully?  If so, I believe it should mention
> what happened to the X- header prefix that was part of 822.  I don't
> believe simply removing them without stating why is a good idea,
> people can draw many different conclusions from that, which affect
> real implementations.

some people think X- headers are extremely useful, others think they 
were a bad mistake that should be eradicated.  maybe we need a separate 
RFC about X- fields.  I'd hate to see this argument block progression 
of 2822 bis.
Permalink | Reply | 64 comments |
headers
Al Costanzo | 2 Jan 16:10
Favicon

Re: Getting 2822 to Draft


I am one of those people that think that the X-Headers are useful since
software we produce uses them also one of those peopel that think MIME has
gone amuck.

I would oppose:

1. Any RFC that completely obsoletes RFC822
2. Any RFC that remove, obsoletes, etc. the X-Headers fields.

Al
----- Original Message ----- 
From: "Keith Moore" <moore <at> cs.utk.edu>
To: "Simon Josefsson" <jas <at> extundo.com>
Cc: "Keith Moore" <moore <at> cs.utk.edu>; <ietf-822 <at> imc.org>
Sent: Friday, January 02, 2004 10:06 AM
Subject: Re: Getting 2822 to Draft

>
> > Would 2822bis obsolete 822 fully?  If so, I believe it should mention
> > what happened to the X- header prefix that was part of 822.  I don't
> > believe simply removing them without stating why is a good idea,
> > people can draw many different conclusions from that, which affect
> > real implementations.
>
> some people think X- headers are extremely useful, others think they
> were a bad mistake that should be eradicated.  maybe we need a separate
> RFC about X- fields.  I'd hate to see this argument block progression
> of 2822 bis.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 2 Jan 16:56

Re: Getting 2822 to Draft


Keith Moore <moore <at> cs.utk.edu> writes:

>> Would 2822bis obsolete 822 fully?  If so, I believe it should mention
>> what happened to the X- header prefix that was part of 822.  I don't
>> believe simply removing them without stating why is a good idea,
>> people can draw many different conclusions from that, which affect
>> real implementations.
>
> some people think X- headers are extremely useful, others think they
> were a bad mistake that should be eradicated.  maybe we need a
> separate RFC about X- fields.  I'd hate to see this argument block
> progression of 2822 bis.

Ignoring the problem won't make it go away, though.  Consciously
removing text is driven by some motivation.  Why not state that
motivation in the document?  Furthermore, if 2822bis fully obsolete
822, without mentioning X- headers, then the X- headers have been
effectively obsoleted.  I don't see how acknowledging that implicit
decision by stating it makes matters worse.

Thanks,
Simon
Permalink | Reply | 62 comments |
headers
Keith Moore | 2 Jan 17:14
Picon

Re: Getting 2822 to Draft


> >> Would 2822bis obsolete 822 fully?  If so, I believe it should
> >mention> what happened to the X- header prefix that was part of 822. 
> >I don't> believe simply removing them without stating why is a good
> >idea,> people can draw many different conclusions from that, which
> >affect> real implementations.
> >
> > some people think X- headers are extremely useful, others think they
> > were a bad mistake that should be eradicated.  maybe we need a
> > separate RFC about X- fields.  I'd hate to see this argument block
> > progression of 2822 bis.
> 
> Ignoring the problem won't make it go away, though.  Consciously
> removing text is driven by some motivation.  

IIRC it was driven by the inability to get agreement on the topic within
the DRUMS WG.

2822 bis will not obsolete 822 in any event - 822 is still a full
Standard, while 2822 bis would only be Draft Standard.  As a practical
matter, nothing can really obsolete 822 as long as people still need to
read old mail messages.
Permalink | Reply | 55 comments |
headers
Arnt Gulbrandsen | 2 Jan 17:22
Picon
Favicon
Gravatar

Re: Getting 2822 to Draft


We went through this before. At the end, noone raised objections against 
the insertion of a sentence such as "X-* header fields are not covered 
in this document". Please, can we just insert that in the list of 
changes and be done?

Quarrelling about whether X-* is useful, a mistake, neither or both is 
not going to help 3822, so let's not do it.

--Arnt
Permalink | Reply | 5 comments |
headers
WJCarpenter | 2 Jan 17:52

Re: Getting 2822 to Draft


km> As a practical matter, nothing can really obsolete 822 as long as
km> people still need to read old mail messages.

I don't think this is a useful consideration, and it is perhaps even
harmful to the discussion at hand.  People (hey, I'm one of those
people) need to read old email in a variety of file formats, and that
includes some that are very like RFC-822.  It also includes many
formats which are widely different from RFC-822.  

Who cares?  

Software that used to understand RFC-822 will not suddenly stop
understanding it unless some implementer does something to make it so,
just as implementers already occasionally, silently do something which
isn't RFC-822 compliant.

In any event, people using RFC-822/2822-ish formats are an order of
magnitude less screwed than those whose archived email gets trapped
inside undocumented proprietary formats.  There are a heck of a lot
more of those people these days, though they don't tend to participate
in IETF discussions.
--

-- 
bill <at> carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3
Permalink | Reply | 0 comments |
headers
Keith Moore | 2 Jan 17:55
Picon

Re: Getting 2822 to Draft


> 
> We went through this before. At the end, noone raised objections against 
> the insertion of a sentence such as "X-* header fields are not covered 
> in this document". Please, can we just insert that in the list of 
> changes and be done?
> 
> Quarrelling about whether X-* is useful, a mistake, neither or both is 
> not going to help 3822, so let's not do it.

well, I do sympathize with the idea that being silent on the subject is
confusing.  but I don't want that discussion to be critical path for 3822.
Permalink | Reply | 4 comments |

Gmane