Brian,
This is a formal appeal addressed to you as IETF Chair and, if
necessary and appropriate, to the IESG, over the recent approval
of draft-ietf-lemonade-mms-mapping-04.txt, "Mapping Between the
Multimedia Messaging Service (MMS) and Internet Mail" as a
proposed standard. The appeal is self-contained and
self-explanatory and proposes both specific and general remedies
to the problems it identifies. It raises questions, not only of
technical content, but of the procedures used to review
documents within WGs as well as between WGs and other areas of
expertise and the mechanisms used to determine adequacy of IETF
consensus.
The appeal necessarily takes no position on whether the problems
demonstrated by this particular document and its approval are
limited to it as an exceptional and deviant case or whether they
have more general implications, but perhaps that is a topic to
which the community should give some consideration in parallel
with your, and the IESG's, evaluation of the specific issues
raised.
regards,
john
This is an appeal of the approval by the IESG of "Mapping
Between the Multimedia Messaging Service (MMS) and Internet
Mail (draft-ietf-lemonade-mms-mapping-04.txt) as a Proposed
Standard. The appeal specifies that the document, as written,
(i) violates an important and long-standing design principle
for Internet applications protocols, does so without
compelling justification, and puts existing deployed and
conforming programs at risk by doing so
(ii) represents a process violation in that substantive changes
were made to earlier versions without review and approval
by the relevant WG
(iii) contains a number of other errors or probably-
inappropriate specifications that strengthen the impression
that the document was approved by the IESG without adequate
evidence of review and consensus in the WG and cross-area
review in the community
It requests that the IESG suspend or withdraw the Protocol
Action Notice, that it refer the document back to the relevant
WG, that the conflict with existing norms either be eliminated
or strong justification for retaining it be provided to the
IETF community and consensus demonstrated that an exception be
justified, and that the WG be asked to review the other changes
suggested.
------------------------
Details:
When the LEMONADE WG was formed, it was established on the
basis of an agreement that it would make no substantive changes
to the Internet mail fabric. That agreement was spelled out in
the charter, which said:
A primary goal of this work is to ensure that those profiles
and enhancements continue to interoperate with the existing
Internet email protocols in use on the Internet, so that
these environments and more traditional Internet users have
access to a seamless service.
That agreement may have led to less intensive review of
LEMONADE products, at least including this one, by members of
the community who were not particularly concerned by work the
WG did within the boundaries of that agreement and the scope
statements based on it. To the degree to which the WG reached
conclusions that pushed the boundaries of that agreement, an
unusually high burden should be placed on it, and the
responsible AD(s), to ensure that any specifications that could
impact the existing email fabric are carefully reviewed in the
broader community. Consensus must be demonstrated that the
changes are both necessary and that they will not cause harm.
Discussion with working group participants and review of the
WG's mailing list archives indicates that the number of
comments on this document received during WG Last Call was
zero. Rather than meeting that high burden of review, there is
no evidence at all that this document was examined by any
significant fraction of the participants in the WG.
This specification violates that principle and agreement. The
handling of the specification as it passed through the WG and
the IESG did not demonstrate the exceptional standard of care
and review that is required to avoid interfering with the
Internet's email fabric. It was also procedurally irregular
even within normal standards of WG and community review. In
particular, substantive changes were made to the specification
between the version that was Last Called (-02) and the version
approved by the IESG (-04), but a review of the WG's mailing
list archive does not show any indication of WG review or
discussion of those changes or of the newer drafts. Indeed, a
review of the WG's archives did not show evidence of any review
or discussion of this document in the last year and a half. We
believe that any post-Last-Call revisions to the substance of a
WG-produced specification must be sent back to that working
group for review and approval, especially if it is probable
that the need for the changes resulted from lack of adequate WG
consideration in the first place.
The overall conclusion that led to this appeal was that the
document is severely defective in several ways and that there
is no evidence that it represents proper review or consensus in
the WG or the IETF more generally. Some, but not all, of what
the appeal considers to be defects might be acceptable in a
Proposed Standard if they had been carefully considered as
tradeoffs within relevant communities of experts, but there is
no evidence --in the document or in the WG archives-- that has
been done. Other defects violate important principles of
Internet mail and should not be permitted except in the absence
of plausible alternatives and evidence of overwhelming support.
Some fractions of these issues, but by no means all of them
are, at least individually and in the opinion of those lodging
the appeal, consistent with the types of rough edges that can
be tolerated, indeed expected, in a Proposed Standard and could
be noted simply for future reference and attention if and when
the specification is proposed for advancement to the next
maturity level. They are included here, as noted above,
largely to illustrate that review and consensus about this
document has been inadequate. There appears to be significant
risk of harm if this document goes forward as standards-track
implementation guidance for the public Internet.
On the assumption that they will be corrected by the RFC
Editor's process, this appeal does not address instances of bad
grammar that make the document harder to follow that is
desirable.
Each identified problem below is followed by a brief statement
of "REMEDY", which is a recommendation about what should be
done if that portion of the appeal is judged to be valid.
Specifically:
(1) In order to allow extensions by private agreements among
interchanging parties, the original definitions of the file
transfer protocol provided that commands starting in "X" would
always be treated as for private use and that such commands
would never be standardized. That model was carried forward
into the email system as private-extension commands in SMTP and
private-extension ("X-") headers in RFC 822. In each case, the
principle has been that we do not standardize such headers or
assign semantics to them in standards-track specifications.
Not only do Email systems all over the net assume that such
headers can be safely discarded, but we have, for years, told
the designers of such systems that they cannot rely on the
interpretation of any such header in the absence of specific
bilateral agreements (and presumed authentication to at least
some level) with the initiator. The requirement that X-headers
be treated in a special way was relaxed with the adoption of
RFC 2822, but remains controversial. At best, it is unwise to
violate the principle in this document unless doing so is
necessary or represents extremely well-established operational
practice.
This specification violates those principles. It provides,
e.g., that an X-MMS-Message-ID arriving from the MMS side
"SHOULD" be mapped into an identically-named header on the
Internet side to facilitate interpretation and conversion of
that header back into an MMS environment. The problem here is
not that the MMS environment has an X-MMS-Message-ID header
(their problem, not IETF's) or that a mapping is required
(although that issue is discussed below), but that the
recommended _Internet_ is "X-MMS-Message-ID" and not
"Message-ID" or "MMS-Message-ID". While the risk of problems
is probably low, the principle is important. More important,
there is no justification for violating the principle: the
guidance given in RFC 2822 (and 822 before it) makes it clear
that the WG could simply define and register "MMS-Message-ID:",
translate whatever relevant form appears in the MMS environment
into it, and then translate back as needed, without violating
the "X-" rule or incurring even a slight risk of conflicts or
ambiguity.
Similar comments apply to X-Priority. The specification
indicates how the X-MMS-Priority header on the MMS side can be
mapped to the widely-used "Importance:" header on the Internet
side. But it then specifies that it is reasonable to map
X-MMS-Priority to "X-Priority:" and then assigns specific field
values to the latter. It isn't good to standardize two fields
with similar semantics: doing so raises interoperability
concerns as different implementations give different
interpretations if both appear. Further confusion is caused by
the fact that "X-Priority" appears to be, as the draft notes, a
class-of-service indication rather than an end-to-end message
importance indicator. But, if there is a need to standardize
or recommend some sort of priority field in addition to
"Importance:", the standard Internet form should not use an
"X-".
REMEDY:
Either remove these proposed mappings or define real,
standards-track, headers, presumably MMS-Message-ID and/or
MMS-Priority, for use in this situation. If two
Importance/Priority fields are to be recommended (or even
not forbidden), specify the semantics when their values are
different.
(2) RFC 822 defined a syntax for use in address fields when it
was desired to not enumerate the recipients, the so-called
"Group syntax". That syntax was carried forward into RFC 2822.
By contrast, we have generally been careful to avoid assigning
semantics to information that appears in comments, or
specifying the text or syntax that should appear in such
comments, at least unless there are no other possibilities.
This specification violates those rules: rather than using the
group syntax specified in RFC 2822, it recommends (even if only
as a "MAY") that a field containing a comment (but no data) be
supplied instead of the group syntax. Interestingly, a
reading the syntax productions of RFC 2822 (or RFC 822)
indicates that
To: (some comment)
is equivalent to
To:
which is not permitted ("To:" requires an address-list) so this
recommendation actually violates the standard and is hence not
tolerable.
In is interesting to note that, while what is done in the MMS
environment does not bind what occurs on the Internet side of
the gateway, the MMS specification (Section 3.2.1.2 of
X.S0016-340-0) provides:
In case there are only blind carbon-copy recipient(s) (Bcc:),
the behavior shall be as recommended by [RFC2821], Appendix
B, i.e. the originating MMS Relay/Server shall only insert an
empty Bcc: header and no To: or Cc: headers. The
recipient(s) shall then only be indicated in the SMTP command
layer (RCPT TO:).
So the 3GPP-produced specification conforming to the
specifications of RFCs 2821 and 2822 while this proposed
gateway specification does not. This is ironic at best.
REMEDY:
Preferred: Use the group syntax with an empty group. If
the LEMONADE WG (or the IESG) are convinced that the
"(undisclosed recipients)" comment is an appropriate
substitute for the group syntax and should be permitted or
encouraged, they should attempt to convince the community
of that conclusion via an update to RFC 2822, not by
(deliberately or accidentally) concealing the change in
this type of document.
Alternate 1: Use a "Bcc:" field that is empty or contains
only a comment, a form that is permitted by both RFC 822
and RFC 2822.
Alternate 2: Do not generate recipient fields. This is
permitted by RFC 2822 but not by RFC 822 and is hence
probably the least desirable valid option in terms of
interoperability.
While a case can be made for any of the three choices, the
choice made in the document is violation of the existing
standards (and their predecessors) and must not be
specified without opening and updating those standards.
(3) The "contemporary email systems" principle of RFC 2821 is
violated. That principle suggests and requires that no new
features or capabilities be added to unextended environments
(i.e., environments conforming to RFC 821 rather than 2821).
The current draft attempts to support the RFC 821 level of
specification where possible, and the 2821 level elsewhere.
This makes makes the specification far more complex and
convoluted than it would be if the mapping that is specified
simply required 2821-based gateways. This extra complexity,
indeed any excess complexity, is undesirable in an Internet
protocol unless it is required by some documented situation or
constraint. This document does not contain any evidence of
such constraints, nor does there appear to be any evidence of
discussion of, much less consensus about, such constraints in
the WG email archives.
REMEDY:
Remove all support for, and discussion of, RFC
821-only email.
(4) Under "Sender address" in Section 2.1.3.2 of the
specification, there is a fairly convoluted discussion of
hidden senders and untrusted relays and receiving servers.
Again, this violates a long-standing, although not specifically
standardized, principle of Internet mail. Stated simply, if
one doesn't trust a relay or any subsequent server in the path
(with the understanding that this raises all of the complicated
issues about what such "trust" actually means), one should not
send the message. This section can be read as attempting to
standardize a bad practice.
More generally, it is not clear that this document is
either a necessary or appropriate place to try to describe or
resolve the complex trust issues involved in mail relaying,
even though the gateway aspect further complicates those
issues. The right solution, actually suggested elsewhere in
the document, is to avoid all attempts to support or guarantee
hidden senders.
REMEDY:
See (6), below.
(5) Under "Content type" in Section 2.1.3.2 of the
specification, reference is made to conversions being done
without "significant loss of content". It is not at all clear
what "loss of content" means, or how "significant" is to be
interpreted.
More broadly, there have been extended, and sometimes quite
heated, discussions in the community during the last few years
about midstream conversions and content alterations of various
sorts (discussions about OPES, VPIM, the FAX WG's "CONNEG"
features, and ongoing discussions about use of message
submission come to mind). Given those discussions, it is quite
surprising that the language in this document, which seems to
suggest "do whatever you want based on your understanding of
what the Internet supports and what you think isn't too
damaging", could move through the WG and be accepted by the
IESG without comment. At as minimum, this is more evidence
that the document was never really reviewed.
REMEDY:
Perhaps the WG intends "...loss of information"
rather than "...loss of content"? "Significant" would
still be an issue, but the intent would be considerably
more clear.
The spirit of the language about gateways in RFC 2821 and
general assumptions about desirable practice in the area
suggests that this specification should permit no
conversions that are not strictly necessary to make the
message conform with standards on the side of the gateway
to which it is being introduced and should make provision
for documenting the conversions that are made.
(6) In section 2.1.3.2.2, under "Sender visibility", the
specification says "Support for sender address hiding is not
included in this version of the mapping document". However,
the discussion of "sender address" in 2.1.3.2 specifies how to
hide a sender address. At best, this is inconsistent. More
generally, invisible sender addresses are an opportunity for
spammers, would add to the difficulties of some proposed
anti-spam techniques, and are a fairly radical departure from
the Internet mail architecture. Not supporting them seems
appropriate but, if LEMONADE ever wants to open that door, it
should be opened as part of an update to base Internet mail
specifications, not through a discussion of syntax in this
document.
REMEDY:
Remove all syntax for sender address hiding and all
discussion of the topic other than the current "does not
support" text or equivalent. This includes removing the
much weaker recommendation, in the security considerations
section, that sender identity hiding not be attempted
across carrier networks. If it is desired to say anything
beyond "does not support", it should be said as part of a
clear explanation of why support for this type of option
is not practical.
(7) In Section 1.3 of the specification, a definition is given
for "Gateway Function". With all respect to ongoing efforts to
better-define the Internet's email model, there is a fairly
extensive definition of gateways and gateway functions in RFC
2821 and the text here is inconsistent with this definition.
Going beyond matters of the terminology in this document, the
provisions of section 2.1.2 of the specification make use of
the term "Relay/Server" inappropriate. If the relevant system
does format, media, or transport conversion, it is a Gateway as
defined in RFC 2821.
REMEDY:
As with the group syntax, if the LEMONADE WG believes that
current, established, definitions are inadequate, the
correct solution is to generate a proposal to update RFC
2821. The definition in this document should either refer
to RFC 2821 (or, where applicable, RFC 2822) or be strictly
consistent with them.
(8) There is an assertion in section 2.1.1 of the specification
about the requirements of SMTP with regard to return paths.
The assertion in the example is incorrect: SMTP _requires_ null
return paths only for error messages involving non-delivery.
The extended requirement that null addresses be used for
automatically-generated messages occurs elsewhere or are
covered by MAY statements or the equivalent in RFC 2821.
REMEDY:
Correct this reference.
(9) This specification provides, in the table of section
2.1.3.1, for a "Resent-Count:" header in Internet mail. This
header is not defined in RFC 2822, which is usually assumed to
be normative for all "Resent-" headers and their relationships.
More important, it violates the important design principle that
one should not provide both a list of things that can be
counted and the count, lest the two counts disagree. If it is
going to do so, text is needed as to what occurs when the
number of Resent field sets and the Resent-count differ. Since
Resent-count does not appear in 2822, it is reasonable to
anticipate that some, probably many, systems will not notice
its presence and hence will not update it when the add
Resent- fields.
It seems completely out of scope for this document unless it
really is going to define a "Resent-count:" field (there is no
definition at present), but it is not clear how a gateway might
calculate such a field given the amount of flexibility in RFC
2822 about which of the Resent- fields may appear and in what
combinations. In the general case, if any Resent- fields
appear, the value of Resent-count could be reliably bounded
only by 1 and the total number of such fields.
REMEDY:
Drop "Resent-count:" entirely in the absence of
compelling need and explanation. If that explanation is
provided, it should be explicit about the relationship
between the count of Resent field sets and the counter if
they happen to differ. It is unlikely that an adequate
definition is possible in the absence of an update to RFC
2822 and mechanisms for changing existing deployed
practice, so such definition is presumably well outside
the scope of the LEMONADE WG.
(10) In Section 2.1.3.2.2, there is a subsection titled
"Resending/Forwarding" that discusses quoting of message
sections and message encapsulation. The quoting mechanism that
is discussed has never been standardized because, while there
seems to have been some convergence in the last few years, the
community has never been able to reach consensus on the
subject. The section appears to be completely confused about
the relationships among quoting or excerpting and embedding.
More important, the encapsulation norm cited, RFC 934, has been
generally considered obsolete (even though still widely used)
since MIME and its encapsulation mechanisms came into general
use. The discussion of that referenced document also appears
normative although the reference is listed as informative (see
item (14), below. There is also a fairly extensive discussion
of forwarding and resending in RFC 2822 and the material in
this section does not appear to be completely consistent with
it.
Similar comments apply to the discussion of Resent- and
Received- headers in the next section. This document should
cite RFC 2821 or 2822 as appropriate, not try to paraphrase
their recommendations (or requirements) and get it even
slightly wrong.
REMEDY:
This document should be rewritten to avoid general
discussions and tutorials of aspects of Internet mail that
are outside the scope of the specific conversions or
mappings being specified. If it is necessary, in the
opinion of the WG, to discuss these additional issues, the
discussions should confine themselves to agreed-up best
practices only or LEMONADE should extend its charter to
include discussion and standardization of common, but
currently non-standard, practices in Internet mail and then
follow up with a document along those lines.
(11) In section 2.1.3.3.1 (apparently), there is a discussion
of "Sensitivity" that indicates that an "appropriate extended
error response code" be used. If this is a protocol
specification, it should specify the code(s) to be used or how
the implementer should determine such code(s). Without that
level of specification, this document is an invitation to
interoperability problems.
REMEDY:
Where codes are intended, they should be specified.
(12) In section 3, it is asserted that SMTP Authentication
protects against misidentification of message source. SMTP
Authentication protects only against misidentification of the
most-recent sender and has little to do with message sources
except through out of band (whether explicit or implicit) trust
chains.
REMEDY:
Correct this text.
(13) The IANA Considerations section, section 4, indicates that
no actions are requested of IANA. However, this specification
introduces several new headers into the Internet mail
environment. Those headers should be registered in the
registry specified in RFC 4021.
REMEDY:
Correctly specify the IANA actions and explicitly identify
the new headers.
(14) While this document specifies in its introduction that an
understanding of the MMS specifications is required to read and
understand it, the MMS specifications are all listed as
informative, not normative. Even if that text did not appear,
the notion of a gateway specification that did not require an
understanding of the definitions of the systems on both sides
would be, at best, very unusual. "You need to understand that
in order to read and implement this" is the very essence of a
normative reference. Apparently neither the WG nor the IESG
did an adequate review to determine which references were
actually normative and which were not. There are fairly
well-defined procedures for normative references to the
documents of other standards bodies in IETF standards-track
specifications; there is no evidence that they have been
followed here.
The reference to RFC 934 raises an additional issue: that
specification's maturity level is listed as "unknown". While
RFC 3967 provides a mechanism for referring normatively to
documents at a "lower level", it is not clear how, or if, one
can refer to a document with status "unknown". Even if RFC
3967 is construed to treat "unknown" as equivalent to the
lowest permitted reference level, there is no evidence in the
WG archives or the Last Call for this document that the
procedures it specifies have been followed here.
REMEDY:
Get rid of the reference to RFC 934 by cleaning up the
material discussed under (10) or, if it is to be retained,
clarify its status (presumably requiring an IETF Last Call
and probably a new document). Move the MMS references to
the "normative" section and make sure that all
requirements for references to such documents have been
met.
(15) In Section 3 (Security Considerations), there is a
paragraph that begins "Since MMS does not include a clear
separation between in-transit envelope and message content,
there are increased risks of unauthorized disclosure of
information, and additional challenges in protecting data. For
example, Bcc recipients do not normally appear in the message
content, only in the envelope; care MUST be taken in...".
This is at variance with the current (cited) version of the MMS
specification, which appears to specify what should be done in
this case very clearly, where it says:
In case there are both To: / Cc: and Bcc: recipients, the
Bcc: headers shall be removed by the originating MMS
Relay/Server and the Bcc: recipients shall only be indicated
in the SMTP command level (RCPT TO:). This is in accordance
with the functionality recommended by [RFC2821], Appendix B.
That statement is not only fairly clear, it is consistent
with the specification in RFC 2821, which the document itself
is not. Whether a MUST-level requirement should appropriately
appear in an example embedded in the middle of the security
considerations section is an issue we will leave for the
editorial process, but, again, it suggests a lack of adequate
review.
REMEDY:
Since the MMS specification is well-aligned with the
requirements of RFC 2821 and 2822, this text and
recommendation should be aligned with it. Gateways should
make as few conversations, and do as little damage, as
possible.
(16) There are a number of mapping issues about which the
document appears to hand-wave, indicating that something MAY be
done but without any specification as to how to do it. The
issue is somewhat similar to that of (11), above, but involves
fundamental design principles that the document does not
address. For example, the document indicates that, if a
Message-ID is not present, "...the value of the
'X-Mms-Message-Id:' header MAY be used" to create one. But
X-MMS-Message-ID doesn't obey the syntax rules for Message-IDs,
so, if traceability is desired, this document needs to specify
how the Message-ID mapping is accomplished. If traceability is
not important, then the document should probably just indicate
that a Message-ID MUST be made up (a requirement of RFC 2822)
and that any handy information, including the contents of an
X-MMS-Message-ID header if present MAY optionally be used to
create it, but that the information will not be useful for
tracing messages or their relationships.
Similar issues arise with addresses. It is common in the MMS
environment for addresses to be E.164-format telephone numbers,
without domain names. The MMS specification makes a
recommendation about how to handle this but it may or may not
be appropriate in all cases. Following precedent in other
areas, it may be appropriate is insert the domain of the
gateway, thereby making the assumption (faulty in X.400 and
faulty here) that forward and reverse paths for these messages
across gateways are necessarily equivalent. Note that
injecting an address without a fully-qualified domain name into
the Internet violates RFC 2821 and RFC 2822.
REMEDY:
The document needs to be specific about mappings when it
is intended that they be useful (e.g., for routing of
messages or message tracing or linking) and to be explicit
when the mappings are for informal documentation purposes
or conformance on one side of the gateway only. If domain
names are made up (e.g., by inserting a gateway domain),
the document needs to discuss the security and operational
implications of doing so.
(17) Another paragraph of the Security Considerations section
reads:
It is possible to hide the sender's identity from
non-recipients using anonymous remailers. It is hard to
hide the sender's identity from recipients when the mail is
cryptographically signed. In view of anti-spam measures it
may be undesirable to hide the sender's identity.
This borders on the silly, since one can eliminate the
particular identity-revealing problem associated with signed
mail by simply removing the signature. More important, it is
not clear why a general discussion of anonymous remailers and
similar tools belongs in this document unless the WG or editor
are just trying to tell us how much they know (and the editor
in this case knows a great deal more than this). The
document repudiates sender-hiding (see (6) above); this is
gateway specification should focus on issues associated with
the gateway, leaving general issues of anonymity in Internet
Mail to other specifications.
REMEDY:
Remove this text unless there is a substantive reason to
include it. If there is, it is going to need significant
reworking including, presumably, addressing the case of
address hiding or exposure with encrypted message body
parts that might contain full RFC 822/ 2822 headers.
(18) The listed of bulleted "existing mechanisms" in the
Security Considerations section is deeply flawed. As noted in
(12) above, SMTP Authentication does not "protect against
misidentification of message source", it merely protects
against spoofing of the previous-hop server. Anything more
requires trust assumptions or agreements about the behavior of
that server that are not covered in this document (or in the
SMTP AUTH one). The document is correct in stating that IPSEC
and SSH or TLS are useful only in protecting against in-transit
modification between adjacent servers, but, if it is going to
make those statements, it should discuss the limitations of
those techniques in an email environment and the particular
difficulties associated with them on the two sides of a
gateway. To do otherwise appears to be a pretense of security
and completeness to pad out the document, one that can be
misleading to readers (whether implementers or users). It also
recommends use of PGP or S/MIME to protect message contents.
This is normally a good recommendation for email, since the
techniques work end to end rather than hop-by-hop. However,
there is a long history of problems when PGP and S/MIME message
privacy and message integrity mechanisms cross gateway
boundaries between systems of a rather different character, and
it is irresponsibile to recommend those techniques without
discussing those potential problems or demonstrating an
understanding of them and providing a pointer to the places
where they have been discussed (such as RFC 2480).
REMEDY:
The Security Considerations generally, and this material in
particular, should be updated to reflect operational
realities and the actual applicability and utility of
techniques in a gateway environment.
(19) It is possible that this should be viewed as a primarily
an editorial comment, but, at this point, we understand how to
construct and write a mail gateway specification. RFC 2821
outlines the basic requirements and we have worked examples for
even more complex cases than this one, e.g., in RFCs 2156 and
2157 and the documents leading up to them. We start with one
protocol and definition as input, figure out which of its
components can be mapped accurately to the other side in terms
of their semantics, specify those mappings, and then examine
the components that cannot be mapped exactly and figure out
what should be done about them -- either dropping them or
producing the nearest possible semantics on the receiving side
while continuing to conform to all of the requirements of the
receiving side. The process is then repeated with the sides
reversed, and then both sides are reviewed to be sure that any
traceability or "reply" considerations are satisfied.
It is key to gateway specification models that the document
make no assumption that the behavior of client or end systems
that receive or send mail that will ultimately pass through the
gateway change in any way. If such changes are desired, they
must be pursued independently, explicitly, and with due
consideration of the likelihood of effective deployment, with
the organizations who have change control of the individual
systems and protocols that feed into the gateway. Unless those
other groups can somehow be expected to be able to instantly
make and deply those changes, the gateway specification must be
[still] written on the assumption that the changes will not
occur or will not be ubiquitious.
Obviously those constraints make the job of the
gateway-specifier harder, but any other assumption is just not
operationally plausible, especially --as is typically the
case-- the end systems assume that they are communicating
within their own environments rather than through a gateway.
This document does not convey the impression that the above
model was followed and all of the steps carefully taken. In
particular, there are mismatches in semantics and mappings that
impact traceability or replies that are not properly accounted
for. Some of those are described above. Others involve
skimming over serious semantic mismatches between the
"Disposition-Notification-To:" header specified in [MDN] and
the "X-MMS-Read-Reply" header. "Replacing" one field with the
other requires pulling information from elsewhere, and the
document provides no guidance as to how to do that. A more
systematic analysis along the lines above would, presumably,
have at least identified the problem and called for some
discussion.
Similarly, since the document is not written clearly as a
gateway specification --with no assumption that it can change
the downstream or upstream environments on either side-- it is
muddled about whether the MDNs it describes are generated by
the gateway or whether they are generated in the MMS (or
Internet mail) environments respectively and then translated by
the gateway. That muddle leads to, e.g., a situation in which
the specification appears to call for mapping of a
Disposition-Notification-To field in an MMS-generated MDN to
an Internet message, but that field will not appear in an
MMS-environment MDN.
REMEDY:
Revoke the Protocol Action notice and return this document
to the WG, insisting that all of the substantive points
above be addressed and that the document not be forwarded
back to the IESG until there is evidence of adequate
review and consensus about the results.
-------------
In several, but certainly not all, of the cases listed above,
there would be little basis for appeal if there were evidence
that the WG had carefully considered the issues, the tradeoffs,
and the possible impact, consulted as needed with others about
them, and then arrived at informed conclusions. However, there
is little or no evidence of such consideration and deliberation
on the part of the WG, at least since version -02 of the
relevant document was posted. In other cases, there has been a
clear failure of adequate review and justification for changes
to the Internet's email fabric and its definitions, changes
that go well beyond the agreed-upon scope of the WG.
In accepting this document for publication as a standards-track
specification, especially after many of the above issues had
been pointed out to it, the IESG either failed in its
responsibility to determine the existence and adequacy of
community consensus or chose to substitute its judgment for
that of a largely-silent WG and broader community without
making an attempt to raise these issues when them. In either
case, the decision to accept this document, in its present
form, as a Proposed Standard should be withdrawn and a review
and revision process initiated.
It is important to stress that this appeal, however lengthy and
detailed, is not a comprehensive review of the document and,
hence, that "fix the points listed in the appeal" is not an
adequate or appropriate remedy. It would be especially
inappropriate if that instruction were delivered to the
document editor as a matter for negotiation with the IESG.
Instead, the details above should be considered as nothing more
than a set of examples whose cumulative impact should be to
demonstrate that this document should be returned to the WG
with instructions to perform the level of analysis, and
guarantee the level of review, that should have preceeded
submission to the IESG as a WG document._______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf