Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

In <4891BF7F.2050506 <at> network-heretics.com> Keith Moore <moore <at> network-heretics.com> 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: chl <at> clerew.man.ac.uk      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

Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

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

Re: I-D Action:draft-reschke-rfc2231-in-http-00.txt

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

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 "=".

It can as well mean LWS "*" EQU, i.e. there can be LWS
before "*", between "*" and "=", or after "=".

Re: I-D Action:draft-reschke-rfc2231-in-http-00.txt

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
> 

2822upd approved

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

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

 Frank

Re: 2822upd approved

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
	tony <at> att.com

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

[Fwd: Protocol Action: 'Internet Message Format' to Draft Standard]

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

	Tony Hansen
	tony <at> att.com

From: The IESG <iesg-secretary <at> ietf.org>
Subject: Protocol Action: 'Internet Message Format' to Draft Standard
Date: 2008-08-26 16:17:15 GMT

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

Re: Protocol Action: 'Internet Message Format' to Draft Standard]

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

Re: Protocol Action: 'Internet Message Format' to Draft Standard]

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

Re: Protocol Action: 'Internet Message Format' to Draft Standard]

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