Re: Email Subaddressing
Bart Schaefer <schaefer@brasslantern.com> Fri, 01 August 1997 20:18 UTC
Received: from cnri by ietf.org id aa05584; 1 Aug 97 16:18 EDT
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA04458; Fri, 1 Aug 1997 16:16:42 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA16209 for ietf-822-bks; Fri, 1 Aug 1997 12:42:24 -0700 (PDT)
Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA16205 for <ietf-822@imc.org>; Fri, 1 Aug 1997 12:42:18 -0700 (PDT)
Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id MAA32498 for ietf-822@imc.org; Fri, 1 Aug 1997 12:46:17 -0700
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <970801124616.ZM32497@candle.brasslantern.com>
Date: Fri, 01 Aug 1997 12:46:16 -0700
In-Reply-To: <19970801183304.16937.qmail@koobera.math.uic.edu>
Comments: In reply to "D. J. Bernstein" <djb@koobera.math.uic.edu> "Re: Email Subaddressing" (Aug 1, 6:33pm)
References: <19970801183304.16937.qmail@koobera.math.uic.edu>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: ietf-822@imc.org
Subject: Re: Email Subaddressing
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-822@imc.org
Precedence: bulk
On Aug 1, 6:33pm, D. J. Bernstein wrote: } Subject: Re: Email Subaddressing } } > Standarizing things has benefits and costs. } } But standardizing user interfaces, no matter how beneficial, is none of } the IETF's business. I'm wondering if we have two separate points of dispute getting mixed into the same argument. The draft as Chris wrote it consists of two major parts: A syntax for subaddresses in local parts, and rules for how various agents should treat local-parts that include subaddresses. I agree that some of the rules for the semantics of subaddressing could intrude on user interface and host policy. The one and only rule that is necessary is that the primary address always identifies the same entity regardless of what subaddress is attached. (If that primary entity wants to dispatch certain subadresses to other entities, that's entirely up to the primary entity or its representative.) Further, the interpretation of local-parts as address plus subaddress can be limited entirely to the host identified by the domain-part; it's neither necessary to require nor necessary to prohibit interpretation by intermediaries like mailing list managers. The syntax, however, is entirely a data format, not a user interface. I think Dan's remark above is directed at the semantics of local-parts; but it's not clear whether the "benefits and costs" remark (sorry, don't remember who wrote it) is referring to the entire draft or only to the syntax dispute. I want to stick to the syntax for now. Even if that syntax is opaque to relays and other intermediaries, it is necessary for it to be transparent to LDAs and submission agents within the interpreting domain. One way to make the syntax transparent is to standardize it; I've been asking for alternatives, but the only suggestion so far is that we throw away combinations of agents that don't already understand one another. Not very helpful either to those who'd like to change existing agents to be able to understand, nor to those who want to write new agents. One alternative that I've thought of is to make it possible to discover the syntax. This is effectively what Dan's ``addalias'' program does by sharing its configuration file. It would certainly be possible to create a simple protocol, possibly as part of the ietf-submit work already in progress, for remote clients to learn the local-part syntax of their server host. However, we've already seen how well such a discovery mechanism works with hierarchy separators in the IMAP4 protocol: To wit, badly, if at all. Nearly everyone agrees that it would have been preferable to pick a hierarchy separator and standardize it, even if that means restricting the mailbox names that the server can present. The situation here is no different; standardizing a character to separate primary address from subaddress is far more workable than standardizing a discovery mechanism, even if it means restricting the primary addresses that a server can support. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing D. J. Bernstein
- Email Subaddressing Chris Newman
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing John C Klensin
- Re: Email Subaddressing Rick Troth
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Craig_Everhart
- Re: Email Subaddressing John Robert LoVerso
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing Craig_Everhart
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Donald E. Eastlake 3rd
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing Donald E. Eastlake 3rd
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Chris Newman
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Donald E. Eastlake 3rd
- Re: Email Subaddressing Bart Schaefer
- Re: Email Subaddressing D. J. Bernstein
- Re: Email Subaddressing Bart Schaefer