Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

SM <> Sun, 15 January 2012 10:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8848121F8470 for <>; Sun, 15 Jan 2012 02:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.635
X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Eu+T15A6wTI for <>; Sun, 15 Jan 2012 02:56:44 -0800 (PST)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id AB68721F846B for <>; Sun, 15 Jan 2012 02:56:44 -0800 (PST)
Received: from (IDENT:sm@localhost []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q0FAuQRs018862; Sun, 15 Jan 2012 02:56:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1326624998;; bh=31c0mpaNQmLUZLjpNxS927T0mzPxnoP+4t3c0TdS07U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=eVN7zTd8S2vfH5XSI6D73aX/+RR4eTLAlh5TidVUgb00voyyr9C+5ZNhOxTqxvwO9 vxuodP4hEm4+F7glrPvaWtEh5rs6CXYPspf+WD5l/feoxwTD5O7F/AHx4tNi4Cu4QC P9uGgnaYGrfIqPuKXb1QsMyKzcLozSGrnNoYfm0A=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 15 Jan 2012 02:53:20 -0800
To: "Murray S. Kucherawy" <>
From: SM <>
In-Reply-To: <>
References: <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <20120114235207.20340.qmail@joyce.lan> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jan 2012 10:56:49 -0000

Hi Murray,
At 20:30 14-01-2012, Murray S. Kucherawy wrote:
>In fact, this was added by RFC5321, and it is this mechanism that 
>this draft is attempting to employ.  So if augmenting Received is a 
>bad idea, I'm left wondering why RFC5321 deliberately enabled it.

I'll comment on the Additional-registered-clauses part only.  The 
Additional-registered-clauses registry was added, in my opinion, to 
keep matters simple.  What made it into RFC 5321 IANA Considerations 
Section is:

   "The registry will contain clause names, a description, a summary of
    the syntax of the associated String, and a reference.  As new clauses
    are defined, they may, in principle, specify creation of their own
    registries if the Strings consist of reserved terms or keywords rather
    than less restricted strings.  As with link and protocol identifiers,
    additional clauses may be registered only by standardization or by way
    of an RFC-documented, IESG-approved, Experimental protocol extension.
    The additional clause name space is for identification and is not
    limited in size: the IESG is encouraged to approve on the basis of clear
    documentation, actual use or strong signs that the clause will be
    used, and a distinct requirement rather than preferences about the
    properties of the clause itself."

The Additional-registered-clauses sub-registry is currently empty as 
the clause is not used in any RFC. I don't have an opinion at the 
moment about what should or should not go into the registry.