--On Thursday, October 18, 2012 07:13 -0400 Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:
On Wed, Oct 17, 2012 at 8:50 PM, Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
I see no way to explain the narrow EAI use case in this
context without either dragging in a whole bunch of EAI that
has no business being here or leaving various things
dangling.
ack. mumble.
So I'll suggest a bit of an amalgam, including a cross
reference of the type I prefer to avoid:
1. State that this removes a restriction that was never
essential.
2. State that the timing of this removal is to accomodate
EAI and for its use of the now-available features, see
[RFCxxxx].
On Thu, Oct 18, 2012 at 6:28 AM, John Levine <johnl(_at_)taugh(_dot_)com>
wrote (with a large part of this distribution list removed):
So, is it better to put in a sentence about representing
non-ASCII text in the group name without including a
replyable address?
The main motivation is to provide a syntax for a
non-replyable address in From: and Sender: headers for cases
where that is appropriate. See the EAI downgrade documents
for a concrete example.
A secondary motivation is to remove an arcane restriction
that has not turned out to be useful in practice.
Dave and John (Levine) are both suggesting an informative
reference from this document to some piece of the EAI
documents (which I guess should be one or both of
draft-ietf-eai-5738bis, Section 7, and
draft-ietf-eai-popimap-downgrade, Section 3.2.1).
Ned and John (Klensin), can you live with that (I know it's
not your preference).
As I said earlier, I can live with almost anything if it is
correct and allows us to move forward. I am, however, getting
more concerned about the consequences to the virtual 5322bis and
its future instantiation if we go down these paths. I would
really not like to be the relevant AD (or Pete-bis) trying to
defend leaving the explanation and reference out of 5322bis
given that they were important enough to include in this
document and, if the explanation and reference go into 5322bis,
why a large series of other references and explanations should
not be included. I'd be a tad happier if this explanatory stuff
when into an appendix rather than the text.
Using a different part of the EAI work as an example, the idea
that it would take little work to get from 5322 to 5322bis goes
completely out the window if the explanation of the syntax of
header fields has to say, effectively, "restricted to ASCII
except when they are not" followed by an explanation and
references.
If you do decide to do this, I slightly prefer Dave's
formulation to John(Levine)'s and prefer my earlier formulation
to either. Borrowing a bit from Ned,
* this restriction is inappropriate given contemporary
practice,
* its incorporation as a syntax rule rather than an
applicability restriction was a matter of convenience
that turned out to be a mistake, so
* we are converting it to an applicability
restriction with the main motivation being to permit an
identifiable (or named) but non-replyable
backward-pointing address where that is necessary and
the special considerations associated with "<>" don't
apply.**
and, if necessary,
* here is a pointer to the application that motivated us
to move forward at this particular time.
As evidence of how silly the syntax restriction is, 5322 syntax
allows a group, non-replyable, address in the one field whose
sole purpose is to provide an address to which one is supposed
to reply ("Reply-to:" of course), creating what might be a high
in silly states.
** Yeah, I know that 5322 doesn't permit "<>" except in
a Return-path, but I've seen that restriction
un-enforced many times too. We could have decided to
make "From:" and "Sender:" use "mailbox[-list] / path"
instead of allowing groups, but the group preserves
somewhat more information -- information that
popimap-downgrade very much needs. I don't think
that explanation belongs in 5322 either.
All: which (or both) should the reference be to?
To the extent to which an explanation or examples are needed, it
has to be popimap-downgrade. But that document is not
particularly well-suited for the purpose, it doesn't contain an
explanation of why empty groups were chosen in preference to
"<>" and more Downgraded-* headers (and shouldn't unless we are
going to start documenting every discarded design alternative),
and we still hope that it turns out to be a moderately
short-term transition mechanism that can gradually fade away
into a historical footnote.
Mumble.
john