[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822

To: Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>
Subject: Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822
From: Tony Finch <dot@xxxxxxxx>
Date: Wed, 31 Aug 2005 18:37:16 +0100
Cc: ietf@xxxxxxxx, ietf-mxcomp@xxxxxxx, spf-discuss@xxxxxxxxxxxxxx
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-mxcomp/mail-archive/>
List-id: <ietf-mxcomp.imc.org>
List-unsubscribe: <mailto:ietf-mxcomp-request@imc.org?body=unsubscribe>
References: <> <>
Sender: owner-ietf-mxcomp@xxxxxxxxxxxx

On Mon, 29 Aug 2005, Frank Ellermann wrote:
>
> > incompatible with RFC2822
>
> I'm still a bit lost how this could actually _break_ something.
> For obvious reasons the author can't say "updates 2822", how
> should he fix it ?  As you said the 822 issue is mentioned in
> the senderid-pra draft.

Regarding RFC 822, the S-ID draft doesn't mention the fact that a large
proportion of software which does something useful with Resent- headers
still implements the 822 syntax, not the 2822 syntax.

Tony.
-- 
f.a.n.finch  <dot@xxxxxxxx>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Follow-Ups:
- Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])
  - From: Frank Ellermann

References:
- Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822
  - From: william(at)elan.net
- Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822
  - From: Frank Ellermann