Subject: Re: Protocol Action: 'Internet Message Format' to Draft Standard]
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Wed, 27 Aug 2008 21:58:21 +0200
List-Id: <ietf-822.imc.org>

Pete Resnick wrote:

>> Something nice, hopefully.
> I think we convinced them of 5321 and 5322. (5+3=8)

Good... just updating all references on pages under
my control (plus en.wikipedia where I care about it)
will take hours, therefore I better wait until the
new links work.

 Frank

Date: Wed, 27 Aug 2008 07:48:30 -0500
To: "Frank Ellermann" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Protocol Action: 'Internet Message Format' to Draft Standard]
Cc: [email-masked], "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

On 8/27/08 at 5:03 AM +0200, Frank Ellermann wrote:

>It's a bit early for 5821 and 5822, I'm curious what they pick now. 
>Something nice, hopefully.

I think we convinced them of 5321 and 5322. (5+3=8)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Protocol Action: 'Internet Message Format' to Draft Standard]
Date:  Wed, 27 Aug 2008 05:03:12 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 8
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Tony Hansen wrote:

> 2821bis and 2822upd will be published together

It's a bit early for 5821 and 5822, I'm curious 
what they pick now.  Something nice, hopefully.

 Frank

Date: Tue, 26 Aug 2008 22:11:49 -0400
From: Tony Hansen <[email-masked]>
To: ietf-822 mailing list <[email-masked]>
CC: [email-masked]
Subject: [Fwd: Protocol Action: 'Internet Message Format' to Draft Standard]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040405020404040201030403
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

fyi. 2821bis and 2822upd will be published together, so this should be
the last hurdle before auth48 both both of those.

	Tony Hansen
	[email-masked]

--------------040405020404040201030403
Content-Type: message/rfc822;
 name="Protocol Action: 'Internet Message Format' to Draft Standard.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="Protocol Action: 'Internet Message Format' to Draft Standard";
 filename*1=".eml"

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Subject: Protocol Action: 'Internet Message Format' to Draft Standard 
Date: Tue, 26 Aug 2008 09:17:15 -0700 (PDT)
Cc: Internet Architecture Board <[email-masked]>,
        RFC Editor <[email-masked]>
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet Message Format '
   <draft-resnick-2822upd-06.txt> as a Draft Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-resnick-2822upd-06.txt

Technical Summary

This document specifies the Internet Message Format (IMF), a syntax for
text messages that are sent between computer users, within the framework
of "electronic mail" messages.  This specification is a revision of
Request For Comments (RFC) 2822, which itself superseded Request For
Comments (RFC) 822, "Standard for the Format of ARPA Internet Text
Messages", updating it to reflect current practice and incorporating
incremental changes that were specified in other RFCs.

Working Group Summary

No working group is currently extant on core email formats. Subsequently,
this document was reviewed on the ietf-822 mailing list, which had been
set up by DRUMS. Pointers to the discussions there were periodically sent
to other mailing lists populated with email people, such as ietf-smtp, the
EAI working group, the LEMONADE working group, and the IMAP-EXT working
group.

Document Quality

The current document represents implementation experience from the past 7
years in email since RFC 2822 was published. As an update intended to move
the internet message format to Draft Standard status, the key issues was
to remove features not implemented by vendors and to tighten down the
specification to represent what has been implemented.

Personnel

Tony Hansen is the Doc Shepherd.  Lisa Dusseault reviewed this for the
IESG.  A number of reviewers from the email community were involved,
including such notables as Ned Freed, John Klensin, and Dave Crocker.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------040405020404040201030403--

Date: Wed, 20 Aug 2008 08:50:55 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: 2822upd approved
Sender: [email-masked]

Yes, this was the last hold up for both documents before AUTH48. The RFC
editor wanted to process the pair together. Stay tuned.

	Tony Hansen
	[email-masked]

Frank Ellermann wrote:
> <http://www.ietf.org/IESG/Implementations/2822-interop-report.txt>
> 
> Last stop:  After AUTH48 2821bis + 2822upd can get their numbers.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  2822upd approved
Date:  Wed, 20 Aug 2008 13:05:06 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 5
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<http://www.ietf.org/IESG/Implementations/2822-interop-report.txt>

Last stop:  After AUTH48 2821bis + 2822upd can get their numbers.

 Frank

Date: Sat, 16 Aug 2008 10:08:11 +0200
From: Julian Reschke <[email-masked]>
To: Frank Ellermann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-reschke-rfc2231-in-http-00.txt
Sender: [email-masked]

Frank Ellermann wrote:
>> Filename        : draft-reschke-rfc2231-in-http-00.txt
> 
> Good.  What's the plan wrt ABNF ?  This memo is harmless
> enough that it could offer both, a normative STD 68 ABNF,
> and an informative appendix using an appropriate mix of
> the 2231 + 2616 BNF.

My plan was to come up with test cases for the current support in user 
agents first. I want to make sure that the spec actually reflects what 
UAs support.

> As it happens the draft already contains an "appropriate
> mix", because it doesn't need the advanced feature of the
> #-rule.
> 
> The general idea of "HTTP does not need continuations"
> could boil down to *WSP for all implicit LWS in the BNF.
> 
> Or in other words replace any "=" by EQU, and specify
> 
> | EQU = *WSP "=" *WSP
> 
> Even if we end up with something slightly more obscure,
> e.g., EQU = [FWS] "=" [FWS], the BNF hides one subtle
> point in <ext-parameter>:
> 
> | ext-parameter = attribute "*=" ext-value
> 
> I _think_ that "*=" actually means "*" EQU in RFC 2231,
> i.e. there can be LWS between "*" and "=".

Yes, that is probably true. The question is: do we want that in the 
profile? I assumed that we want to reduce the number of places where WS 
is allowed.

> It can as well mean LWS "*" EQU, i.e. there can be LWS
> before "*", between "*" and "=", or after "=".
> 
> I think it does _not_ mean LWS "*=" LWS remotely in the
> direction of an *= operator.

My hope was to make it exactly that, in order to make parsing simpler.

But yes, this is an open issue; I'll do some testing with 
Content-Disposition as implemented in practice. There's no point in 
putting it into the ABNF if we have evidence that those UAs that do 
support RFC2231 do not allow it (remember: the reason for a profile is 
to cut out the unnecessary stuff).

BR, Julian

Date: Mon, 4 Aug 2008 20:18:13 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Sender: [email-masked]

Charles Lindsey writes:
> Yes, but that all changed when the IETF agreed to standardize POP3 and 
> IMAP, which are clearly "message stores",
> ...

I think that if you look at little more closely at IMAP, you will find 
this assumption to be incorrect.

IMAP specifies many things, very few of them are about the message store 
itself. Most of what IMAP has to say is about how the client talks to 
the server and vice versa. The message store is a gaping area of 
unspecified behaviour (intentionally, and it has both positive and 
negative effects).

RFC 3501 section 5.1.1 regulates how mailbox hierarchies behave, surely 
an important part of how a message store works. Guess how much text and 
how many MUSTs that involves.

Arnt

To: [email-masked]
Xref: clerew local.mime:5477
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15
Date: Mon, 4 Aug 2008 13:09:17 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>But the idea of a message store wasn't part of the original internet 
>mail architecture. So it's not clear to everyone where its 
>responsibilities lie.  If the message store is (as I believe) a part of 
>the recipient's user agent then it should be neutral with respect to 
>storing messages except when given explicit instructions by the recipient.

Yes, but that all changed when the IETF agreed to standardize POP3 and
IMAP, which are clearly "message stores", even though it is clear that
they are acting solely on behalf of the recipient who, theoretically, has
absolute contol over them (in practice, the recipient has to put up with
whatever his ISP deigns to provide :-( ).

But we still have to decide whether, in the course of introducing this
header, we want to specify any additional behaviour (or absence thereof)
for the POP3 and IMAP documents.

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