Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
SM <sm@resistor.net> Wed, 24 September 2008 06:22 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85FE3A6D32; Tue, 23 Sep 2008 23:22:36 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005BB3A6D32 for <ietf@core3.amsl.com>; Tue, 23 Sep 2008 23:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDGkm+MCfT87 for <ietf@core3.amsl.com>; Tue, 23 Sep 2008 23:22:34 -0700 (PDT)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id C8FAE3A67B2 for <ietf@ietf.org>; Tue, 23 Sep 2008 23:22:34 -0700 (PDT)
Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m8O6MSv7024395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 23:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1222237359; x=1222323759; bh=uD0ZoUYotHwhvgKHyHCSvBsXzKnoFMlqiOF9 riTVR7U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=n3ALCqGk5YkHzrTcfZr074mnNj qCVtv/Weky9ocs4Sq4gb93ooe5Wc1r6IaMD9FmoPmrnLglFxzcybUqX+oqhw8xGcAkv AWVw7RiucrwkkaKGZQvdqevq2YOq7nSIvjeX5YDHGK4ovL4HCwLDkI+dazz3tabiwez swCiKOHJLGY=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=1qh6D2FN7LqbrmyNN8hqw0gvKgzuoVmedJ0KR+x2LI+oT0IQJKoU4/y1jW2h3N0m1 b8Tx/BUWKfmpUwN67p/FvzaYIEa7Gi+lE2D7Ehmpa8AF7nr2RCjawZUVX++ugTtFSYo 4QMCXxLDDfErEo/7EfM+1O9/VOgHOQ07B2lAZTo=
Message-Id: <6.2.5.6.2.20080923215214.030a7ce0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 23 Sep 2008 23:22:13 -0700
To: ietf@ietf.org
From: SM <sm@resistor.net>
Subject: Re: Last Call: draft-ietf-usefor-usepro (Netnews Architecture and Protocols) to Proposed Standard
In-Reply-To: <878wtksxuk.fsf@windlord.stanford.edu>
References: <6.2.5.6.2.20080906004844.0333aff0@resistor.net> <878wtksxuk.fsf@windlord.stanford.edu>
Mime-Version: 1.0
Cc: ietf-usefor@imc.org, Russ Allbery <rra@stanford.edu>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
At 19:44 21-09-2008, Russ Allbery wrote: >(I am not a subscriber to the ietf list and would appreciate copies of >replies.) Cc as requested. >The message is still meaningful; however, it violates a SHOULD in RFC 2822 >(well, sort of, depending on how you interpret "belong" in the case of an >address that by definition doesn't belong to anyone). The message may be meaningful for a broadcast but not for two-way communication. For example, if you were reading this mailing list and replying to this message through Netnews, I would not be able to send you a reply. As obfuscated mailboxes such as example@example dot nospam dot com are commonly used in Netnews, proposing ".invalid" as a suffix at least ensures that the mailboxes is actually invalid. >I think a gateway has two acceptable choices: preserve the From header and >violate the SHOULD, or replace the From header with some contact address >for the gateway (a copy of the Sender header, for example). From a >quality of implementation perspective, as a consumer of a gateway, I'd >much prefer the former behavior. In this case, it may be better to violate the "SHOULD" and provide an valid mailbox to which replies can be sent (second choice). >Regardless, however, news-to-mail gateways are not standardized by this >draft, so I don't think this is an issue for this document. See 3.10.1: > > From the perspective of Netnews, an outgoing gateway is just a > special type of reading agent. The exact nature of what the outgoing > gateway will need to do to articles depends on the medium to which > the articles are being gated. > >I think work on a best-practices guide for gateways would be great, but I >think the e-mail side of the gateway is outside the scope of this >document. Section 3.10.1 mentions practices that are encouraged. As the document "creates" the problem, it may be good for the document to address it especially given the different interpretations of "meaningful". I suggest the following in Section 3.10.1: 5. The message should be compliant with the specifications for that medium. >This wouldn't be a gateway; it would be transmission of a news article >through e-mail. See 3.10: I suggested that as an alternative to work around the issue if you prefer not to fix the invalid address. >Yes, thank you. I now have: > > 2. The proto-article is sent as an email with the addition of any > header fields required for an email as defined in [RFC2822], and > possibly with the addition of other header fields conventional in > email such as To and Received. The existing Message-ID header > field SHOULD be retained. I don't see the need for specifying additional headers. You could keep it simple with the following: 2. The proto-article is sent as an email with the addition of any header fields required for an email as defined in [RFC2822]. The existing Message-ID header field SHOULD be retained. >Hm. Well, if we were to add a new header field, it really needs to go >into USEFOR and not here, since USEFOR is the canonical document for >header fields for netnews articles. USEFOR has already gone through Last >Call, however. > >I can see your point here, but I'm not sure the lack is particularly >important. I'd really rather not see us make further changes to USEFOR; >generally an X-* header is used for this and is adequate in practice. Each implementation might use a different header field name. It's might become a problem in future. >Well, this is very explicitly an example based on a specific >implementation, which happens to use an X-* header. But I can see where >this would be less than ideal. However, as above, I'm hesitant to invent >a new header for this purpose and add the necessary machinery for >registering it when there is no standardized existing practice and it's >not clear what issues are involved in picking a header field, >standardizing its format, and so forth. Implementors will likely pick X-Gateway as you mentioned that header name in the example. Once people start using specific headers, it's difficult to depreciate them in favor of some standardized format. Regards, -sm _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … SM
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … Russ Allbery
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … SM
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … Russ Allbery
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … SM
- Re: Last Call: draft-ietf-usefor-usepro (Netnews … Tony Hansen