Subject: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Oct 2012 11:57:22 +0200

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-leiba-5322upd-from-group-06

Reviewer: Roni Even

Review Date:2012-10-17

IETF LC End Date: 2012-11-6

IESG Telechat date:

Summary: This draft is almost ready for publication as a standard track RFC.

Major issues:

Minor issues:

1.	It is not clear from the draft what the use case for using the group
construct is.  Section 3 talks about the issues with using the group
construct and recommend limited use, but this is the only information.
2.	Section 2.1 says "If the sender field uses group syntax, the group
MUST NOT contains more than one mailbox."  Why use a group name for a single
mailbox?

Nits/editorial comments:

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Oct 2012 10:49:55 -0700 (PDT)

> construct and recommend limited use, but this is the only information.

The main driver for this work is to add support for EAI downgrade mechanisms,
although a good case can also be made that the present restrictions on group
usage are silly, limiting and unnecessary. (The silliness arises from the
observation that these restrictions enforced by most agents in the field.)

It is far from clear that it makes sense to clutter up this very clean and
crisp specification with a bunch of EAI use case scenarios, especially since
this is an update to RFC 5322 that could in theory be merged into the main
document in the future. A decision taken long ago for both RFC 5321 and 5322
was to keep them as free of entanglements with technology that's layered on top
of them (e.g., MIME, various SMTP extensions) as possible.

In any case, the decision of the group was not to do this.

> MUST NOT contains more than one mailbox."  Why use a group name for a single

Why not? I'm sorry, but this question makes no sense. A group is a
characteristic attached to a collection of zero or more addresses. A group
containing a single member is every bit as valid as a construct as a group
containing 20 members. Or zero, for that matter.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Oct 2012 11:30:53 -0700

> The main driver for this work is to add support for EAI downgrade mechanisms,

Although the Intro text cites this, it doesn't explain how the change 
will help.  Nor is this explained elsewhere in the document.

A single sentence summarizing what benefit is achieved with the change, 
along with a couple of usage examples, would go a long way towards 
showing how this update helps in practical ways.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Oct 2012 12:00:05 -0700 (PDT)

> showing how this update helps in practical ways.

I could live with a single sentence, but I strongly object to the inclusion
of examples, for the reasons I gave in my original response.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Oct 2012 15:27:31 -0400

--On Wednesday, October 17, 2012 12:00 -0700
[email-masked] wrote:

>> A single sentence summarizing what benefit is achieved with
>> the change, along with a couple of usage examples, would go a
>> long way towards showing how this update helps in practical
>> ways.
> 

Would a possible middle ground be to include a single
well-crafted sentence with an informative citation of
draft-ietf-eai-popimap-downgrade?  That document does contain
examples and an explanation of that particular use case.

I'd prefer to avoid that entirely for the same reasons Ned
cites, but it would, IMO, be good to get on with this rather
than quibbling for days or weeks.

    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Oct 2012 13:26:31 -0700

> examples and an explanation of that particular use case.

I thought Ned's goal was -- quite reasonably, IMO -- to not be dependent 
upon EAI for this general-purpose enhancement.

d/

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Oct 2012 17:16:31 -0400

--On Wednesday, October 17, 2012 13:26 -0700 Dave Crocker
<[email-masked]> wrote:

>...
>>>> the change, along with a couple of usage examples, would go
>>>> a long way towards showing how this update helps in
>>>> practical ways.
>>> 
> I thought Ned's goal was -- quite reasonably, IMO -- to not be
> dependent upon EAI for this general-purpose enhancement.

The problem is that all of the practical (i.e., not constructed
just for the document) examples we have, especially with the
advice to not use these group addresses except under special
circumstances, are associated with EAI.  So, as soon as one says
something equivalent to "summarize the benefit and provide use
cases" one either becomes dependent on EAI for examples (which
is not what we usually mean by "dependent") or is constructing
works of fancy or speculation.

The other approach --and the one I think Ned is advocating
although he can speak for himself-- is to make this change
primarily because embedding the prohibition on using groups in
backward-pointing addresses in the syntax has outlived its
usefulness if, indeed, it was ever wise.  Instead, we end up
with the syntax restriction eliminated and rather general
use/applicability advice.  It seems to me that ought to be
sufficient.

    best,
    john

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Oct 2012 14:32:29 -0700 (PDT)

> than quibbling for days or weeks.

Channeling my inner Maslow, I see the present text as best, an additional
sentence or two as next best, a sentence and a cite to the downgrade doc next
in line, and including actual EAI examples in this doc as the worst choice.

FWIW.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Oct 2012 16:19:06 -0700

> in line, and including actual EAI examples in this doc as the worst choice.

The problem I have with the current text is that it says 'what' 
motivated the change, but not how it is useful for the intended class of 
uses.  The reader is left entirely to guess.

Self-actualization among the inadequately-informed invites fantasy more 
than it invites utility.

d/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 17 Oct 2012 19:45:58 -0400

>> sentence or two as next best, a sentence and a cite to the downgrade doc
>> next in line, and including actual EAI examples in this doc as the worst
>> choice.
>
> The problem I have with the current text is that it says 'what' motivated
> the change, but not how it is useful for the intended class of uses.  The
> reader is left entirely to guess.

So, is it better to put in a sentence about representing non-ASCII
text in the group name without including a replyable address?

Or is it better to remove the notation about the EAI use case, and
just say that it's stupid to have the restriction, so we're removing
it?

I'm ambivalent.

Barry

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Oct 2012 17:18:37 -0700 (PDT)

> Self-actualization among the inadequately-informed invites fantasy more

That depends on both the utility and the desirability of repeating the existing
use case, doesn't it? The EAI use case of downgraded messages is one that only
exists because of a nasty confluence of restrictions and which we absolutely do
not want to see repeated in any other context.

If you really think this is important to explain why we're making this change
against the overall context of RFC 5322 - and I most certainly do not agree
that it is important to do so - then the best "use case" to add is the negative
one: The elimination of an unnecessary restriction that isn't followed in
practice.

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. Either way the average reader looking at general
message usage isn't going to get it, and the more you try and waltz around this
the more likely you are to get exactly the outcome you fear: Someone is going
to see some sort of parallel with some problem they are trying to solve (some
sort of deliberate form of address obfuscation scheme immediately comes to
mind) and proceeds to make a mess of things.

				Ned

P.S. It really would be best if this could wait until there was an update
to RFC 5322. But that's not how the timing has worked out, so this is the
best alternative available.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Oct 2012 17:50:17 -0700

On 10/17/2012 5:18 PM, Ned Freed wrote:
> If you really think this is important to explain why we're making
> this change against the overall context of RFC 5322 - and I most
> certainly do not agree that it is important to do so - then the best
> "use case" to add is the negative one: The elimination of an
> unnecessary restriction that isn't followed in practice.
>
> 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].

d/

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Oct 2012 17:50:08 -0700 (PDT)

> just say that it's stupid to have the restriction, so we're removing

If the alternative is to dig into EAI in any depth at all, the latter is far
preferable.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Oct 2012 07:13:15 -0400

On Wed, Oct 17, 2012 at 8:50 PM, Dave Crocker <[email-masked]> wrote:
> So I'll suggest a bit of an amalgam, including a cross reference of the type
> I prefer to avoid:
>
>    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 <[email-masked]> wrote
(with a large part of this distribution list removed):
> 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).  All: which (or both) should the reference be to?

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Oct 2012 09:45:35 -0400

--On Thursday, October 18, 2012 07:13 -0400 Barry Leiba
<[email-masked]> 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:
>> 
>>    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 <[email-masked]>
> 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
> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2012 06:50:53 -0700

> when into an appendix rather than the text.

The job of the current draft is to be sufficient to its purpose.  Its 
purpose is to augment a base document with a specific revision.

An update segment document does not typically have the purpose of 
including extensive annotations for possible later use, attempting to 
anticipate or hypothesize later editing efforts, to revise the base 
document.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2012 18:25:34 -0700

> I have wondered about that limitation for at least 15 years. I
> have come up with possible explanations but without a shred of
> evidence from the RFCs.

FWIW,

The construct of "group" is pretty much an assertion of an aggregate 
identity.  That is, an identity beyond that of the listed addressees, 
deriving from their, ummmm... grouping.

The purpose of From: and Sender: is to assign bits of essential 
responsibility.

Unlike the current trend towards declaring personhood for corporations, 
the design motivation behind using the group construct was to restrict 
assignment of responsibilities to individuals, rather than aggregations 
of them.

All very abstract, I admit.  From the vantage point of some decades, 
even quaint.

d/

---

From: Bill McQuillan <[email-masked]>
Date: Thu, 18 Oct 2012 17:51:28 -0700

On Thu, 2012-10-18, John C Klensin wrote:
<snip>

> when into an appendix rather than the text.  

<serious value="false">
How about we put the explanation right next to the justification in 
5322 why <group> was not allowed in From: in the first place?
</serious>

<snip>
-- 
Bill McQuillan <[email-masked]>