Subject: [lemonade] Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail"

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jun 2005 12:16:28 -0700

A process appeal has been raised on this document by John Klensin.
The document for that appeal has been attached.  One one point
raised, that the document was changed between IETF Last Call
and passage by the IESG, I will note that the author and I (as
shepherd of the document) believed the changes made to be
editorial clarifications rather than critical to the mechanisms
agreed to by the WG.    I expect that the working group will
be involved in future discussion of this issue, and I encourage the
WG to review the appeal.
			regards,
				Ted Hardie

>Date: Fri, 10 Jun 2005 14:49:17 -0400
>From: John C Klensin <[email-masked]>
>To: Brian E Carpenter <[email-masked]>
>X-Scan-Signature: 58a894dbf8d0c4c152ea0be9e8cd3d14
>Cc: Randall Gellens <[email-masked]>, [email-masked], [email-masked]
>Subject: Appeal of decision to standardize "Mapping Between the
>  Multimedia Messaging Service (MMS) and Internet Mail"
>X-BeenThere: [email-masked]
>List-Id: iesg.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
>	<mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>X-QUALCOMM-AV: Sophos AV Testing
>
>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
>
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Fri, 10 Jun 2005 12:37:07 -0700 (Pacific Daylight Time)

I have read John Klensin's appeal.  I do not wish to comment on the 
process issues, as doing would likely lead to a collosal waste of my time.

However, John's technical objections seem to be largely excellent; and his 
suggested remedies seem to offer great benefit while causing negligible 
(if any) harm to this proposed specification.

Unless there is harm that I missed (I admit that I have not studied it in 
detail), I suggest that adopting John's suggestions in entirety would be 
the best course for the proponents of this specification.

Although doing so would leave the process issues unanswered, it would 
greatly reduce their impact.  I personally am willing to accept an 
unintended process bypass if the technical work is otherwise excellent.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jun 2005 12:55:33 -0700

Speaking as a technical contributor, I think there are serious problems
with his proposed remedies, and that he has missed the aim on some
of this pretty widely.

As an example:

>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.

While I would certainly consider shifting SHOULD to MAY here
(since facilitating the passage of an MMS header across the
Internet and back to MMS seems to be not required even if
desirable), I think translating the X-* headers to standards
headers is the wrong way to go.  These *are* private use
headers from the Internet perspective and the specification as
it stands allows them to be treated as such--they can be wantonly
dropped by an intermediate MTA, for example.  Translating them into
standards-based headers means that they must be retained, and
I believe is far more liable to confusion about what they will mean
on the Internet side of the gateway.  They should mean nothing to
the Internet recipient.   That is, I believe, how the Internet recipient
getting an unknown X-header will treat it now, and I see no
advantage to putting them into something "Message-ID" which is
extraordinarily liable to misconstruction.

As before, just my view as a technical contributor.
			regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 10 Jun 2005 13:33:15 -0700 (Pacific Daylight Time)

On Fri, 10 Jun 2005, Ted Hardie wrote:
> dropped by an intermediate MTA, for example.

If they are indeed private-use headers from the MMS standpoint, and 
utterly meaningless in Internet, then they should be *dropped*, not 
translated into something else.

The moment that you state in an Internet specification that such-and-such 
is written with an X-* header, you have effectively standardized that 
header.

You can be certain that IMAP clients will start requesting that header, 
and demanding that servers enforce the correct syntax.

> Translating them into
> on the Internet side of the gateway.

But that is exactly what the document does; by naming a header it has 
declared it to be a standards-based header.

There are three ways out of the predicament.  Pick your favorite poison:

1) Do as John says, and give them a real name.

2) Require that these headers be dropped.

3) Require that these headers be wrapped inside a Comments: header, e.g.,
 	Comments: X-MMS-Message-ID: blurdybloop

I do not consider it be acceptable (or permissible) to have a X-* header 
with defined semantics yet claim "we're really not defining this header or 
its semantics."

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jun 2005 15:04:34 -0700

At 1:33 PM -0700 6/10/05, Mark Crispin wrote:
>But that is exactly what the document does; by naming a header it 
>has declared it to be a standards-based header.

 From my point of view, naming something does not make it standards based,
especially since the name itself lets you know it is not.  Mentioning something
in a document with the clear message "This is not an Internet header" does
not make it an Internet header.

>1) Do as John says, and give them a real name.

As I said before, I think that makes it much harder to let people know that
they are *not* Internet headers.

>2) Require that these headers be dropped.

I believe that allowing the headers to be dropped is sufficient, but I
would prefer requiring they be dropped to giving them Internet semantics
by dropping the X-.

>I do not consider it be acceptable (or permissible) to have a X-* 
>header with defined semantics yet claim "we're really not defining 
>this header or its semantics."
>

But there are no defined semantics for the Internet; it is simply the case
that if they happen to make it across the Internet to some other 
MMS-capable device,
they are in the same form they started out in.  For any consumption by
Internet mail, they are garbage.  They can be dropped by any device along the
path and ignored if they are consumed an Internet mail user agent.

Again, my personal technical opinion,
				regards,
					Ted

---

From: Mark Crispin <[email-masked]>
Date: Fri, 10 Jun 2005 15:17:46 -0700 (Pacific Daylight Time)

On Fri, 10 Jun 2005, Ted Hardie wrote:
> especially since the name itself lets you know it is not.

That may be a viable position to hold if we lived in a world in which 
everyone is rational and cooperative.  Unfortunately, we do not live in 
such a world.

> Mentioning 
> something

I contend that you greatly underestimate the problem of individuals who 
will take text from an RFC out of context and demand that their resulting 
interpretation is the One True Way, notwithstanding explicit text 
elsewhere in the same RFC to the contrary.

> they are *not* Internet headers.

Such arguments would be more convincing if there was a compelling reason 
to believe that they are not headers.  They certainly appear to be 
perfectly good informational headers to me.

> would prefer requiring they be dropped to giving them Internet semantics

OK, we have a point of agreement that requiring these to be dropping is 
acceptable.  Good, we have a fallback that we can both sign off on.

> But there are no defined semantics for the Internet; it is simply the 
> case that if they happen to make it across the Internet to some other 
> MMS-capable device, they are in the same form they started out in.

I'm afraid that this sentence is self-contradictory; or at least to me it 
is.  I'm reading at least two defined semantics for these headers in the 
Internet:
  1) informational data relating to how the message is transported in MMS
  2) data to be passed when transporting the message back to MMS

That's quite a bit.

> For 
> any consumption by Internet mail, they are garbage.

Is that really true?  Are you saying that no human user will ever care 
about this information; that that information is utterly useless for any 
debugging or tracing purposes; and that this information being utterly 
useless should not be passed back to MMS if the message loops back for 
whatever reason?

> They can be dropped 
> by any device along the path and ignored if they are consumed an 
> Internet mail user agent.

I disagree.  If the header appears, people will pay attention to it and 
attempt to use the data contained.

The only way to get the semantics of "garbage" is mandatory dropping.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jun 2005 16:19:22 -0700

At 3:17 PM -0700 6/10/05, Mark Crispin wrote:
>That may be a viable position to hold if we lived in a world in 
>which everyone is rational and cooperative.  Unfortunately, we do 
>not live in such a world.
>
>>Mentioning something
>I contend that you greatly underestimate the problem of individuals 
>who will take text from an RFC out of context and demand that their 
>resulting interpretation is the One True Way, notwithstanding 
>explicit text elsewhere in the same RFC to the contrary.

Care to give your estimate of the numbers of these individuals 
creating that problem,
just so I know?  In percentage of readers, say?

>
>I'm afraid that this sentence is self-contradictory; or at least to 
>me it is.  I'm reading at least two defined semantics for these 
>headers in the Internet:

1 should be something that the the Internet does not care about, at least in
my view.  2, I would recast as "data to be passed back to MMS, if available",
and I contend that it still has no semantic meaning to the Internet.  Since
*any* X- header can be dropped, the MMS system should not rely on it
being present, and no intermediate non-MMS system would do anything
special about it all.  If they have a local policy to drop unknown 
X-headers; cool.
If they have a local policy to pass on unknown X-headers; cool.

>That's quite a bit.

We apparently disagree here.

>>For any consumption by Internet mail, they are garbage.
>
>Is that really true?  Are you saying that no human user will ever 
>care about this information; that that information is utterly 
>useless for any debugging or tracing purposes; and that this 
>information being utterly useless should not be passed back to MMS 
>if the message loops back for whatever reason?
>
>>They can be dropped by any device along the path and ignored if 
>>they are consumed an Internet mail user agent.
>
>I disagree.  If the header appears, people will pay attention to it 
>and attempt to use the data contained.
>

Maybe my brain left early for the weekend, but this seems contrary to existing
practice for  X- headers.  It seems now, we leave it up to local policy to
act (or not act) on them; this seems to require a specific policy to drop them.
I cannot see why that policy should be required here where it is not required
in general.  If I mis-understand you, and you really mean that all intermediate
MTAs should drop all X- headers, then I think that's consistent but 
unnecessary.

			regards,
				Ted Hardie

---

From: Mark Crispin <[email-masked]>
Date: Fri, 10 Jun 2005 16:27:13 -0700 (Pacific Daylight Time)

On Fri, 10 Jun 2005, Ted Hardie wrote:
>> interpretation is the One True Way, notwithstanding explicit text elsewhere 
>> in the same RFC to the contrary.
> Care to give your estimate of the numbers of these individuals creating that 
> problem,

I can't give such numbers.

I can, however, say that the trouble raised by such individuals is greatly 
out of proportion to their numbers.  There is, for example, a widely 
distributed IMAP server implementation that contemptously thumbs its nose 
at the IMAP specification and is a major source of headache for me.

> and I contend that it still has no semantic meaning to the Internet.

What if I start polluting the Internet with X-MMS-* headers that are 
completely bogus and would cause harm if inserted into the MMS world? 
Then, when the MMS world complains, I point at that bit in RFC 2822 that 
says that X-* headers are experimental and I can put whatever crap in such 
headers that I desire?

Of course, I wouldn't do this.  Nevertheless, the right way to look at 
this is not to consider how reasonable people behave.  It's to consider 
how unreasonable people behave.

> Since
> special about it all.

s/can be dropped/can contain any random crap that someone puts in

> Maybe my brain left early for the weekend, but this seems contrary to 
> existing practice for X- headers.

That's because, prior to now, no specification stipulates that such 
headers are to be generated.  This document now says that such headers are 
to be generated under such-and-such conditions.  Now, there are meaningful 
X-* headers with defined semantics.

> If I mis-understand you, and 
> you really mean that all intermediate MTAs should drop all X- headers, 
> then I think that's consistent but unnecessary.

No, I mean that headers from the MMS world must either be represented with 
real headers, or they are to be dropped.  They should not be rendered into 
Internet X-* headers.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Jun 2005 17:07:42 -0700

At 4:27 PM -0700 6/10/05, Mark Crispin wrote:
>completely bogus and would cause harm if inserted into the MMS 
>world? Then, when the MMS world complains, I point at that bit in 
>RFC 2822 that says that X-* headers are experimental and I can put 
>whatever crap in such headers that I desire?
>
>Of course, I wouldn't do this.  Nevertheless, the right way to look 
>at this is not to consider how reasonable people behave.  It's to 
>consider how unreasonable people behave.
>
>>Since

So, I don't see any point to debate the right point of view here; we clearly
differ on that and on the role of this specification in managing it.  But I do
see a way of describing what you're putting forward as a threat into a
Security Consideration, so that might be valuable if this document gets
revised (or later re-spun at Proposed, if it does not).

>>>I disagree.  If the header appears, people will pay attention to 
>>>it and attempt to use the data contained.
>>Maybe my brain left early for the weekend, but this seems contrary 
>>to existing practice for X- headers.
>
>headers are to be generated.  This document now says that such 
>headers are to be generated under such-and-such conditions.  Now, 
>there are meaningful X-* headers with defined semantics.

We continue to disagree with whether specifying how they are 
generated in a gateway
has anything to do with their semantic content and/or how they are treated
outside that gateway.  Existing practice for anything other than the gateway
doesn't change here--if you would drop X-Newsreader, you can drop this.
I don't see why mentioning the creation in an RFC changes the ability to
apply local policy.

I'll be off-list until Monday,
				regards,
					Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 17:08:10 -0700

>  Speaking as a technical contributor,

Speaking as an IETF participant, I find it troublesome that the cognizant 
area director of an effort would also seek to participate as a direct 
contributor to that effort.  

It does not take much consideration of process management issues to see 
the inherent conflict of interest created by such a dual role.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 17:09:54 -0700

>  From my point of view, naming something does not make it standards based,

sorry.  i thought we were discussing a specific document intended for standards 
track.  

the idea that a standards track document can provide specification for something 
that is, itself, not standardized, is intriguing but mostly seems oxymoronic.

  d/
  ---
  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jun 2005 17:16:30 -0700

>  agreed to by the WG.

The technical problems with the current draft are substantial, and one might 
even say fundamental.  John's appeal is nicely focussed and pragmatic.

As much as I tend to view John's notes as painfully verbose, I was 
struck by the number of items he cited AND that I thought every one of 
them significant.

The cumulative effect is to feel quite simply that this document needs a 
thorough consideration by the working group and that a) it is nowhere 
near ready for publication, and b) it certainly never got proper wg 
review.

With respect to one suggestion made, namely to simply adopt all of 
John's suggested changes, I think that we and the IESG can't get off 
that easy.  First of all, John's note makes the explicit point that he 
has only listed examples.  He sees more in the document to work on.  And 
second, the underlying problem with the document is that it did not get 
the diligent review of the working group that is needed.  Wholesale 
approval of John's suggested changes would not fix this necessary step 
of community review.

  d/
  ---
  Dave Crocker

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 11 Jun 2005 11:04:12 -0700 (PDT)

On Fri, 10 Jun 2005, Ted Hardie wrote:

> my view.

While what you wrote is all true, to me X- header field is something that 
is specifically not standardized - none of them. Where as we appear to be 
trying to do just that.

Additionally I would note that unless I understand things wrong, any fields
that are unknown to MTA/MSA/MUA are totally ignored (same as with X- fields),
so why would it make a difference if we have these MMS fields named as X-MMS-
or MMS- if either case they are going to be ignored by internet MTAs?

So is there really any arguments on that if these fields have MMS-
prefix it could actually be bad or hurt any program operations?
(as opposed to just arguing that its not the right prefix)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Antony Bowesman <[email-masked]>
Date: Mon, 13 Jun 2005 11:25:50 +0200

> it stands allows them to be treated as such--they can be wantonly

I don't understand the benefit of defining a standardised way of achieving 
mapping using non standardised headers.

The MIXER approach to use X400-* headers to tunnel private information seems a 
more sensible approach than adding X- headers.  It seems clearer (and cleaner), 
if I want to add some MMS specific handling to my gateway, to extract semantic 
significance from a MMS- header than an X- one.

 > extraordinarily liable to misconstruction.

I see no extra confusion caused to the average internet recipient by retaining, 
fex. MMS-Transaction-Id: in a message compared to X- headers, such as the 
following in the message

X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-BeenThere: [email-masked]

I expect the average internet recipient doesn't know or even care what headers 
are in a message, most of which are never shown by the average MUA, and is very 
unlikely to understand the significance of the X- prefix in a header.

Regards
Antony

---

From: Tony Hansen <[email-masked]>
Date: Mon, 13 Jun 2005 07:36:12 -0400

IMHO, x- headers should never be standardized.

Unfortunately, I made an assumption when I originally reviewed this
document that the use of "x-" was acting as a placeholder and would be
removed before publication. That was my mistake.

To repeat: x- headers should never be standardized.

	Tony Hansen
	[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 12:37:15 -0700

>the inherent conflict of interest created by such a dual role.

Dave,
	This is a much larger question than lemonade.  I encourage
you to write a draft stating your opinion that the cognizant area
directors should not act as technical contributors to  the efforts for
which they hold management responsibilities.  I believe Brian would
be the right person to shepherd such a document, once you had
gotten support for it.  I've cc'ed him to let him know I've recommended
that course of action.  If you do take that course of action, please
let me know where you will discuss it, as I have some comments on
the proposal that don't really belong in lemonade.
	At the moment, however, I believe RFC 2026 is still in
force.  It says, in section 5:

    While it is recognized that entities such as the IAB and IESG are
    composed of individuals who may participate, as individuals, in the
    technical work of the IETF....

	Prefacing my comments with "as technical contributor"
and ending such comments with things like "my personal opinion"
are ways of highlighting that I an individual participating in the
technical work of the IETF, not acting in any particular role.
			regards,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 12:52:23 -0700

>  This is a much larger question than lemonade. 

Actually, Ted, I was attempting to attend to a very narrow question that is 
quite specific to lemonade.  

You are the cognizant AD for this working group. As is typical for environments 
that have any concern for conflicts of interest, the IETF history is to have the 
cognizant AD not be a direct contributor to the working group effort.  This 
keeps the authority issues notably simpler.

You have chosen to take an active, technical role in the working group 
discussion.  I was trying to point out to you the problem this causes.  I chose 
the working group forum in order to get it on the record and to suggest to 
others that we have a particularly awkward situation,.

Given that there is now a rather substantial, formal appeal against your actions 
concerning this working group's efforts, I was trying to suggest that you cease 
your efforts to sway the group's technical discussions.

>  technical work of the IETF....

NOT in the activities they are overseeing, Ted.  

 d/
  ---
  Dave Crocker

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 13:28:42 -0700

>keeps the authority issues notably simpler.

Having the Area Director directly manage a working group under himself
or herself would clearly be a conflict of interest; some would argue that
having an Area Director manage a working group in the same area would
also be a conflict.  Having an Area Director be a document author
in a working group under his management might create the same
conflict, and it would certainly require that a different Area Director
sponsor the document while the author recused himself or herself
from the ballot.

But are you appear to be saying that an Area Director should make no technical
contribution to the discussion of a working group on the matters before it,
unless he or she is speaking as an Area Director.

>your efforts to sway the group's technical discussions.

The formal appeal is on an IESG action:

"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."

If you are arguing that this is a special case because there an 
existing appeal,
I misunderstood you.  But that would then imply that no IESG member should
enter the technical discussion on the mailing group list, and I think that is
problematic as well.  In general, if IESG members do not express 
their technical
opinions on public lists, then the interaction with the technical community
is limited in really unfortunate ways.  I think the exchange with Mark was
quite useful, even though there remain things about which we do not agree; we
could have had it privately, of course, but how does that help?

>NOT in the activities they are overseeing, Ted.

Again, I agree that having an individual manage himself or herself as a
working group chair is over the line under most circumstances (Ned did
it in one special case, as I recall, as a co-chair), and that there has to
be real care taken when the role is as document author.  But I think
an AD would be hamstrung in his interaction with a working group
if he could not make technical comments on the ongoing work or the
issues that came up.  And I think it is a change in our process to
try to make that so.

			regards,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 13:49:48 -0700

>  unless he or she is speaking as an Area Director.

Not "appear to be" Ted.  I am saying it simply and directly.

What YOU appear to be missing is that the instant the cognizant area director 
becomes a technical advocate, they lose the ability to hold the moderating 
position that is needed for a direct-line management position in a public 
decision process.

For any issue that needs to be escalated to the area director, when there is a 
debate about how to resolve it, how the heck can anyone expect "impartiality" 
from an area director who has been an advocate?

I will also note that active participation by the cognizant area director can 
create some confusion, not the least of which is by that area director, 
themself.  

It is not too difficult to imagine that a directly contributing cognizant AD 
could fail to distinguish when they should turn something to the group to 
decide, versus when it is appropriate for the AD to make a decision directly.

Oops.  That's the process point of the current appeal.

>  The formal appeal is on an IESG action:

Right.  Like the cognizant AD had nothing to do with that decision?

>  If you are arguing that this is a special case because there an

I am arguing that the existing appeal is the final nail in the coffin of the 
error in being both cognizant AD and direct contributor.

>  enter the technical discussion on the mailing group list, and I think that

In the midst of an appeal, pretty much correct.  Absent recusal from the 
authority role.  Except that you can't recuse yourself after the fact.  You can, 
however, cease direct attempts to sway the working group decision discussions.

>  opinions on public lists, then the interaction with the technical community

Here I am, making a very precise distinction between those activities over which 
an AD has direct authority and those they don't, and here you are repeatedly 
missing the point.  

The history has been very simple:  An AD that wants to directly participate must 
not have direct oversight for that activity.

  d/
  ---
  Dave Crocker

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 14:57:16 -0700

>position that is needed for a direct-line management position in a public

Does the phrase "speaking as an Area Director" in my statement above
still hold for you, or do you, in fact, mean:  "An Area Director should
make no technical contribution to the discussion of a working group
on the matters before it?"?

>from an area director who has been an advocate?

Under most circumstances, the working group process avoids this.
There are points at which the working group process calls consensus
and if a technical contributor's public opinion is in the "rough" or "rough
consensus", it's pretty obvious.  It's certainly happened to me as
a technical contributor both before and after becoming an AD, in
Lemonade as one example.   If you get to one of the disputes
envisioned in RFC 2026, section 6.5.1, it gets escalated to the
Area Director(s) for the area in which the WG is chartered--that is,
both of them.  Having both involved is a check to ensure impartiality,
and there are further backstops from there.

In any case, silence does not equate to impartiality or lack thereof.  Silence
could simply mean that the Area Director did not contribute an 
opinion, not that
the AD didn't have one.  And if that opinion isn't made public so that
it can be commented on and, if necessary, rejected, aren't we a lot
worse off?

>Oops.  That's the process point of the current appeal.

For what it's worth, I think the John's is a good use of the right to 
appeal.  There
were changes between 02 and 04, and the authors and IESG made a judgement
call on whether they were clarifications or substantive.  The IESG 
makes judgement
calls on that all the time--sometime it's easy (moved a reference, made the BNF
compile); sometimes it's not so clear.  The appeals process is there 
to make sure
there is a recourse when someone in the community disagrees, and I think John's
using it well.  I may still disagree with him at the end of the day, 
but I believe
he's asking a good question.

But that doesn't go to individual participation of the Area Director 
on the mailing
list.  John's document makes several technical arguments about how X- headers
are understood in this document.  Going through that, I think he's 
starting from
a position that describing the gateway function's behavior for x- 
headers creates
an imposition on non-gateway Internet MTAs and MUAs.  I don't agree
with that, as my reading is that the behavior for non-gateway Internet M*s
is that everything stays the same--they get to apply local policy.  Stating
that opinion in response to Mark's produced what was to my view a
useful technical exchange and helped expose where our assumptions differ.
Not stating that opinion would have left us with less data.

<snip>

>  An AD that wants to directly participate must

And I believe that the current practice is that an AD who wants to run a
working group or edit its document should not have direct oversight,
but that ADs do make technical contributions to their working groups
by participating in them.  In ECRIT, where I am not the cognizant
area director, for example, I have seen Jon give technical advice based
on his knowledge of the formats in use (he was the document author
for PIDF-LO).  He's also asked questions, had disagreements with
contributors, and lost some arguments.  He's been, in other words,
a technical contributor.

If you think differently, I believe you need to write a document that
amends 2026.  It doesn't spell out "ADs cannot contribute
technical comments to mailing lists of working groups for which they
are Area Advisor".  It *does* say that ADs are expected to be technical
contributors to the IETF, and the base technical contribution in the
IETF is mailing list participation.
			regards,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 15:12:57 -0700

Ted,

>  on the matters before it?"?

Again, you seem to be entirely missing my point.  You have been taking positions 
of active advocacy.  That is a very, very long way indeed, from making 'no 
technical contribution'.  

A cognizant area director must not be an active contributor to the technical 
discussion and, in particlar, must not take advocacy positions, unless they 
recuse themselves from being cognizant ad.

There is nothing particularly subtle, complex or unusual about such a stricture.

> >  For any issue that needs to be escalated to the area director, when
> >  there is a debate about how to resolve it, how the heck can anyone
> >  expect "impartiality" from an area director who has been an advocate?
> >

Right.  No one participating in the working group process is going to worry 
about statements from the cognizant AD, as indications of clear biases the 
cognizant AD is likely to later show during a management intervention by them...

>  In any case, silence does not equate to impartiality or lack thereof.

No kidding.  But it sure does lock down biases.

>  But that doesn't go to individual participation of the Area Director on
>  the mailing list.  John's document makes several technical arguments about
>  how X- headers are understood in this document.  Going through that, I

Ted, you really don't get it, do you?

A cognizant area director has an authority rolein the process.  An authority 
role does not permit "equal" participation, no matter how differentially the 
participation might be labeled.

So, please stop attempting to sway the group's technical discussion.

If you have so little faith in the working group's technical and discussion 
skills, to believe that it can reasonably resolve these issues, then there are 
larger process issues to discuss.

  d/
  ---
  Dave Crocker

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 16:56:50 -0700

>participation might be labeled.

No, Dave, I get it and *I disagree*.  The extension of your argument is
that no AD can have "equal" participation, since they can cast a DISCUSS
and no IAB member can have "equal" participation, since they will
eventually hear any appeals.  There has to be some line between
"Anything goes" and the reductio ad absurdam, and I believe it
is placed at:  no direct working group chair/AD overlap and no
document overlap/document sponsorship.  I think saying that
the Area Advisor can't have and express a technical opinion
doesn't work.   It's "advocacy" or "swaying" just as much
as any other technical comment, and I believe as long as it
is in the technical realm it is both okay and a contribution to transparency.
Pushing it past the working group over objections would not be advocacy,
that would be abuse.

And, since you've skipped this point several times, I'll repeat.  I don't
think your point of view is justified in our documents.  If you think
it should be, you should get them changed.

				regards,
					Ted

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 17:12:38 -0700

Ted,

>  eventually hear any appeals.  

Unless they recuse themselves, which is what they do.

But the cognizant AD can't do that.

So please stop your own efforts at arguing ad absurdum.  My statements have been 
formulated carefully.  Your responses are tenaciously eliminating that care.

>  it should be, you should get them changed.

I've been trying to focus on a core issues about reasonable behavior by a 
cognizant area director.

the amount of ietf common behavior that is not documented is legion.  the amount 
that IS documented but is ignored is too.

we don't document that area directors are prohibited from shooting working group 
chairs.

does that make it ok to shoot them?

  d/
  ---
  Dave Crocker

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 17:36:38 -0700

>does that make it ok to shoot them?

Dave, if we documented that every participant could shoot working group chairs
and explicitly said Area Directors were participants, but really meant they
could only shoot working group chairs in other areas, we would need to
document that too.

Have a pleasant evening, Dave,
			regards,
				Ted

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 16:32:36 -0700

> explicit text elsewhere in the same RFC to the contrary.

But this argument is not helpful, since there is no way to satisfy 
such people since by definition they are not reasonable.

>  Such arguments would be more convincing if there was a compelling 
> reason to believe that they are not headers.  They certainly appear 
> to be perfectly good informational headers to me.

Giving such headers a official name *would* be standardizing them, 
which would be confusing, I think.

>>  would prefer requiring they be dropped to giving them Internet semantics

I don't think we can *require* that the headers be dropped, since we 
can't demonstrate any interoperabuility problems by retaining them.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is a life-size picture of a dogcow conveniently located in the
Finder. Look under "Page Setup..."  Now look under "Options."  Like
any talented dog, it can do flips. Like any talented cow, it can do
precision bitmap alignment.                   --Apple Tech Note #31

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 16:53:49 -0700

At 4:27 PM -0700 6/10/05, Mark Crispin wrote:

>  What if I start polluting the Internet with X-MMS-* headers that 
> are completely bogus and would cause harm if inserted into the MMS 

Regardless of what the gateway specification says or does not say, 
you are able to do this today.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Algol was a great improvement on most of its successors.
                                          --C.A.R Hoare

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 16:55:37 -0700

> there are meaningful X-* headers with defined semantics.

I'm confused.  The existing wording says nothing about *generating* 
x-mms- headers.  It also says nothing about semantics of such headers.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
For best results, be sure to double clutch when you paradigm shift.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:00:13 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
> But this argument is not helpful, since there is no way to satisfy such 
> people since by definition they are not reasonable.

Nevertheless, if there are obvious protocol/document fixes that preempt 
even an out-of-context quote from being interpreted wrongly, those fixes 
should be made.

I spent extravagant amounts of time on the IMAP specification doing just 
that, because I had to do so.

> Giving such headers a official name *would* be standardizing them, which 
> would be confusing, I think.

Defining such headers in a document which is purportedly standards-track 
is standardizing them.  The only way to prevent that is to remove them 
from the document.

In RFC 822 (RFC 2822 is silent on the matter) X-* headers are a "protected 
set of names" for "user-defined fields".  RFC 822 is still technically the 
standard........

Headers gatewayed from MMS do not constitute a "user-defined field".

> I don't think we can *require* that the headers be dropped, since we can't 
> demonstrate any interoperabuility problems by retaining them.

The interoperability problem is created the instant any client interprets 
them for any reason whatsoever.  As these are X-* headers, anybody can 
send non-MMS email filled with such headers and containing any crap I want 
(but designed to cause torment to any entity which attempts to interpret 
them).

I suspect that when the MMS community fully comprehends what this means, 
this mailing list will be filled with their voluable protests.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:02:14 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
>> completely bogus and would cause harm if inserted into the MMS world? Then, 
>> when the MMS world complains, I point at that bit in RFC 2822 that says 
>> that X-* headers are experimental and I can put whatever crap in such 
>> headers that I desire?
> Regardless of what the gateway specification says or does not say, you are 
> able to do this today.

Yes...but...

If I start spewing forth MMS-* headers that cause pain and suffering to 
some program that cares, a case can be made that I am an abusive sender; 
and consequently administrative and other sanctions should be taken 
against me.

No such case can be made about X-* headers.  By definition, they're the 
user's playground/jungle.

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:02:34 -0700

At 11:25 AM +0200 6/13/05, Antony Bowesman wrote:

>  I don't understand the benefit of defining a standardised way of 
> achieving mapping using non standardised headers.
>
>  The MIXER approach to use X400-* headers to tunnel private 
> information seems a more sensible approach than adding X- headers. 
> It seems clearer (and cleaner), if I want to add some MMS specific 
> handling to my gateway, to extract semantic significance from a 
> MMS- header than an X- one.

The existing MMS system uses X-MMS-* headers.  This is not something 
we can change.

The question is how to treat such headers when a message is received 
from an MMS system.

The existing text says almost all such headers SHOULD or MAY be 
dropped.  The exception is X-MMS-Message-Id, where it says SHOULD be 
retained.

Please see section 2.1.3.2 Conversion of messages from MMS to Internet format
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
What is mind?  No matter.
What is matter?  Never mind.
        --Thomas Hewitt Key, 1799-1875

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:03:40 -0700

>  IMHO, x- headers should never be standardized.

I don't think we are standardizing them.

-------------- Randomly-selected tag: ---------------
All true wisdom is found on T-shirts.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:13:26 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
> The existing text says almost all such headers SHOULD or MAY be dropped.  The 
> exception is X-MMS-Message-Id, where it says SHOULD be retained.

There's also (at a quick glance) X-Mms-Message-Class and X-Priority.

The text should say that all should headers MUST be dropped or converted 
into headers that do not start with "X-".

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:10:09 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
> I'm confused.  The existing wording says nothing about *generating* x-mms- 
> headers.  It also says nothing about semantics of such headers.

The generation is by the gateway, in producing a message for the Internet 
mail infrastructure.

The semantics are section 2.1.3.2 of the document, e.g.:

     An 'X-Mms-Message-Id:' header, if present, SHOULD be retained.

The effective meaning of this statement is: when encountering an 
X-Mms-Message-Id header in an MMS message, you SHOULD generate an Internet 
header line with field name of "X-Mms-Message-Id" and field contents from 
the X-Mms-Message-Id header in the MMS message.

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:25:38 -0700

At 5:00 PM -0700 6/14/05, Mark Crispin wrote:

>  Defining such headers in a document which is purportedly 
> standards-track is standardizing them.  The only way to prevent 
> that is to remove them from the document.
>
>  In RFC 822 (RFC 2822 is silent on the matter) X-* headers are a 
> "protected set of names" for "user-defined fields".  RFC 822 is 
> still technically the standard........

The problem is that the MMS community has already standardized such 
headers for their own use.  If a gateway specification makes no 
mention of such headers it won't be very useful.  The gateway 
specification must deal with the reality of MMS.

Note that the current text says "MAY" or "SHOULD" drop all such 
headers except for X-MMS-Message-ID.  If the group feels that this 
header, too, should say "SHOULD drop" I won't object.  But if you are 
saying there can't be any mention of X- headers then we are really at 
an impasse.

>  Headers gatewayed from MMS do not constitute a "user-defined field".

The headers exist.  The question is what to do with them.  Currently, 
the text allows a gateway to retain or drop, with a preference to 
retain, and does not assign any semantics.  I don't see that as 
standardizing such headers.

>>  I don't think we can *require* that the headers be dropped, since 
>> we can't demonstrate any interoperabuility problems by retaining 
>> them.
>
>  The interoperability problem is created the instant any client 
> interprets them for any reason whatsoever.  As these are X-* 
> headers, anybody can send non-MMS email filled with such headers 
> and containing any crap I want (but designed to cause torment to 
> any entity which attempts to interpret them).

This is the case with any header, X- or not.

-------------- Randomly-selected tag: ---------------
All probabilities are 50%.  Either a thing will happen or it won't.
This is especially true when dealing with someone you're attracted to.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:27:13 -0700

At 5:02 PM -0700 6/14/05, Mark Crispin wrote:

>  If I start spewing forth MMS-* headers that cause pain and 
> suffering to some program that cares, a case can be made that I am 
> an abusive sender; and consequently administrative and other 
> sanctions should be taken against me.
>
>  No such case can be made about X-* headers.  By definition, they're 
> the user's playground/jungle.

I find it difficult to believe any ISP or organization would take 
this stance.  I suspect that if you start spewing headers designed to 
cause grief, your organization/ISP will take the same action 
regardless of the X- prefix.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The only problem with being a man of leisure is that you can
never stop and take a rest.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:28:37 -0700

At 5:10 PM -0700 6/14/05, Mark Crispin wrote:

>  The generation is by the gateway, in producing a message for the 
> Internet mail infrastructure.
>
> X-Mms-Message-Id header in an MMS message, you SHOULD generate an 
> Internet header line with field name of "X-Mms-Message-Id" and 
> field contents from the X-Mms-Message-Id header in the MMS message.

So your argument is that passing a header through is the same as 
generating it?  I hadn't realized that, which is why I was confused.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Look Bruce, the bat signal!!!

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 17:36:57 -0700

At 5:13 PM -0700 6/14/05, Mark Crispin wrote:

>> dropped.  The exception is X-MMS-Message-Id, where it says SHOULD 
>> be retained.
>

The text says:	The 'X-Mms-Message-Class:' header MAY be retained.

There's not much difference between 'MAY be retained' and 'MAY be 
discarded'.  I agree the wording does convey a slight preference, but 
that's all.

>  The text should say that all should headers MUST be dropped or 
> converted into headers that do not start with "X-".

I think converting into non-X headers is worse than allowing the 
headers to stay or be dropped.  To convert into non-X headers would 
be standardizing the semantics of such headers.  It also creates new 
problems, since we will undoubtedly see messages that have both the 
X- and the non-X versions of the headers, with different values.

-------------- Randomly-selected tag: ---------------
Windows users often swear at their PC's whereas Mac users often
swear by their Macs.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:41:43 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
> The problem is that the MMS community has already standardized such headers 
> for their own use.  If a gateway specification makes no mention of such 
> headers it won't be very useful.  The gateway specification must deal with 
> the reality of MMS.

That's irrelevant.  MMS is not Internet email.  Their specifications, 
standards, and requirements are of no concern to us except for how it 
affects a gateway between MMS and Internet email.

If the MMS specification stated that all messages contained:
 	Reply-to: [email-masked]
you would consider it absurd to say that MMS requires that all messages 
gateways to the Internet must be replied to George Bush.

Clearly, in such a case, the meaning of that header has to be understood 
*in the MMS context*, and a header with equivalent meaning *in the 
Internet context* has to be generated in its place.

Apparently, X-Mms-Message-Id does not have the meaning of "user defined 
field" in the MMS context.  If the data from that header is to be passed 
to the Internet, it should not be passed as data that has the meaning of 
"user defined field" in the Internet context.

> Note that the current text says "MAY" or "SHOULD" drop all such headers 
> except for X-MMS-Message-ID.  If the group feels that this header, too, 
> should say "SHOULD drop" I won't object.  But if you are saying there can't 
> be any mention of X- headers then we are really at an impasse.

I guess that you'll have to break the impass, because there is going to be 
a howl of protest at any standardization of X- headers for anything other 
than "user-defined field"; and that is what the document as currently 
constituted does.

> The headers exist.  The question is what to do with them.

Convert it from X-Mms-Message-Id to Mms-Message-Id.

Or, if you prefer, MMS-X-Mms-Message-Id.

Or even Mark-Crispin-is-a-crackpot-X-Mms-Message-Id.

Just don't inflict a document which defines *Internet* messages with X- 
headers that are anything other than "user-defined fields".

>> them for any reason whatsoever.  As these are X-* headers, anybody can send 
>> non-MMS email filled with such headers and containing any crap I want (but 
>> designed to cause torment to any entity which attempts to interpret them).

No, because it's abuse to generate a non X- header with that purpose, and 
sanctions can be imposed on the abuser.

It is not abuse to do so with an X- header.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:46:50 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
>> and consequently administrative and other sanctions should be taken against 
>> me.
> I find it difficult to believe any ISP or organization would take this 
> stance.  I suspect that if you start spewing headers designed to cause grief, 
> your organization/ISP will take the same action regardless of the X- prefix.

In doing so, that organization/ISP would open itself up to a very 
expensive lawsuit.

It is difficult enough for ISPs to get rid of spammers that they 
inadvertantly acquired as customers, even when there are TOS and AUP 
forbidding it.

How well can an ISP can take punitive action against someone who uses a 
protocol according to the protocol specification??  It says right here, 
"user-defined field".  I'm a user, I defined it.  What's the problem?

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 17:54:44 -0700 (Pacific Daylight Time)

On Tue, 14 Jun 2005, Randall Gellens wrote:
> So your argument is that passing a header through is the same as generating 
> it?  I hadn't realized that, which is why I was confused.

Of course it is.

MMS and Internet mail each have their own standards and specifications. 
Consequently, a gateway between the two must accept a source message, and 
use that message as data to generate a destination message.

A null transformation of a datum by the gateway is permissible only when 
that datum is identical with identical semantics in both.  In Internet 
mail, X-* headers have the semantics of "user-defined field".  They 
therefore can not be used to represent MMS headers which have different 
sematics.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 18:00:59 -0700 (Pacific Daylight Time)

> The text says:	The 'X-Mms-Message-Class:' header MAY be retained.

Stating that thereby defines, as an exception to the long-establish rule 
of X-* headers being "user-defined field", that the "X-Mms-Message-Class" 
field name identifies data in an MMS-origin message which was conveyed in 
the X-Mms-Message-Class header.

That is the problem.

> discarded'. I agree the wording does convey a slight preference, but 

The problem is the MAY, not "retained" or "discarded".

> I think converting into non-X headers is worse than allowing the headers to 
> stay or be dropped.

Allowing the headers to stay is a non-starter.

Therefore, you are saying that the headers must be dropped.  Fine.  Make 
that change.

> To convert into non-X headers would be standardizing the 
> semantics of such headers.

An example of those semantics would be:

The MMS-X-Mms-Message-Class header in Internet mail identifies data in an 
MMS-origin message which was conveyed in the X-Mms-Message-Class header.

There's nothing wrong with that.  Someone may even appreciate having such 
a header.

> It also creates new problems, since we will 
> undoubtedly see messages that have both the X- and the non-X versions of the 
> headers, with different values.

Not if you add a prefix instead of removing the X-.

If MMS-X-Mms-Message-Class doesn't work, then how about 
From-MMS-X-Mms-Message-Class?

-- Mark --

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Jun 2005 20:44:13 -0700

At 5:46 PM -0700 6/14/05, Mark Crispin wrote:

>>> suffering to some program that cares, a case can be made that I 
>>> am an abusive sender; and consequently administrative and other 
>>>   No such case can be made about X-* headers.  By definition, 
>>> they're the user's playground/jungle.
>> this stance.  I suspect that if you start spewing headers designed 
>> to cause grief, your organization/ISP will take the same action 
> inadvertantly acquired as customers, even when there are TOS and 
> AUP forbidding it.
>
>  How well can an ISP can take punitive action against someone who 
> uses a protocol according to the protocol specification??  It says 
> right here, "user-defined field".  I'm a user, I defined it. 
> What's the problem?

I don't think you'd win that lawsuit, just as I don't think the ISP 
cares about an X- prefix.  If you are crafting messages to cause 
harm, waving the RFCs doesn't strike me as likely to be of much use.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 14 Jun 2005 21:03:01 -0700

On Tue, 14 Jun 2005, Randall Gellens wrote:
> I don't think you'd win that lawsuit, just as I don't think the ISP cares 
> about an X- prefix.  If you are crafting messages to cause harm, waving the 
> RFCs doesn't strike me as likely to be of much use.

I'm sending a perfectly standards-compliant Internet message, it's not 
spam (perhaps it's to a mailing list that I have ever right to use), some 
crank at some other site says that it crashes his MUA, and my ISP 
terminates me based upon the say-so of that crank?

I don't think so.  ISPs have a hard enough time getting rid of spammers 
without cancelling legitimate customers just because someone doesn't like 
that customer's MUA's use of X-* field names in headers.

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Wed, 15 Jun 2005 09:39:18 +0100

On Wed Jun 15 05:03:01 2005, Mark Crispin wrote:
>> I don't think you'd win that lawsuit, just as I don't think the 
>> ISP cares about an X- prefix.  If you are crafting messages to 
>> cause harm, waving the RFCs doesn't strike me as likely to be of 
>> much use.
> 
> I'm sending a perfectly standards-compliant Internet message, it's 
> not spam (perhaps it's to a mailing list that I have ever right to 
> use), some crank at some other site says that it crashes his MUA, 
> and my ISP terminates me based upon the say-so of that crank?

Another argument, and one possibly more to the point, is that if a 
mail filter program or MTA chooses to drop, or worse, replace the 
header with a private use field (Perhaps it's Mark's Message System, 
and it deploys its own internal message id to avoid duplicates), then 
someone will raise a bug report against it.

Are they right to do so?

The same argument applies to X-Priority and X-Mailer, of course. The 
question is whether introducing another essentially standard "X-" 
header - and this document does appear to do so - is making the 
problem worse or not.

Ted made the assertion that the X-MMS-Message-Id header can never 
mean anything to an internet recipient - I'd like to see, for my own 
peace of mind, whether this is really the case. My suspicion is that 
an MMS-aware Internet MUA may well find a use for it, but my 
knowledge of the MMS standards is precisely zero.

Given the opportunity to change the specification such that it maps 
the X-MMS-Message-Id MMS header onto an MMS-Message-Id Internet 
header, my inclination would be to do so, likewise with 
X-MMS-Message-Class.

My inclination would also be to drop the references to X-Priority. 
While there's no point in pretending it doesn't exist, the Importance 
header is the standard one. I'd see no problem in referring to 
X-Priority/Importance mappings in a non-normative Appendix, of course.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Jun 2005 09:59:00 -0700

At 9:39 AM +0100 6/15/05, Dave Cridland wrote:

> header with a private use field (Perhaps it's Mark's Message 
> System, and it deploys its own internal message id to avoid 
> duplicates), then someone will raise a bug report against it.
>
>  Are they right to do so?
>
>  The same argument applies to X-Priority and X-Mailer, of course. 
> The question is whether introducing another essentially standard 
> "X-" header - and this document does appear to do so - is making 
> the problem worse or not.
>
> mean anything to an internet recipient - I'd like to see, for my 
> own peace of mind, whether this is really the case. My suspicion is 
> that an MMS-aware Internet MUA may well find a use for it, but my 

I'd be fine with changing the text to say "MAY drop" X-Mms-Message-ID 
and X-Mms-Message-Class, which would make them the same as the other 
X-Mms-* headers.

> While there's no point in pretending it doesn't exist, the 
> Importance header is the standard one. I'd see no problem in 
> referring to X-Priority/Importance mappings in a non-normative 
> Appendix, of course.

I'd be fine with moving all mention of X-Priority to an informative Appendix.

-------------- Randomly-selected tag: ---------------
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.                                           --Mark Twain

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Jun 2005 12:31:06 -0700

At 5:54 PM -0700 6/14/05, Mark Crispin wrote:
>A null transformation of a datum by the gateway is permissible only 
>when that datum is identical with identical semantics in both.  In 
>Internet mail, X-* headers have the semantics of "user-defined 
>field".  They therefore can not be used to represent MMS headers 
>which have different sematics.
>

But is this a null transformation?  The view of X- headers in the two 
systems is
such that I think it's reasonably to read it as a transformation from
"semantically valid" to "semantically null".  As long as the X-MMS header
is on the Internet side of the gateway, it is semantically null because there
is no user definition of the field.  True, it got made "semantically null" by
being copied verbatim into a system which treats strings starting X- in a s
pecial way, but it still got transformed as a result, didn't it?

I'm also somewhat confused about what you think "user defined" implies
in the current Internet case.  I see lots of X- headers that are clearly
parts of larger systems or are otherwise non-individual user defined
headers (brightmail poetry, for example).  Why are OMA-defined headers
different here?
			regards,
				Ted Hardie

---

From: Dave Cridland <[email-masked]>
Date: Wed, 15 Jun 2005 20:52:49 +0100

On Wed Jun 15 17:59:00 2005, Randall Gellens wrote:
>>  Given the opportunity to change the specification such that it 
>> maps the X-MMS-Message-Id MMS header onto an MMS-Message-Id 
>> Internet header, my inclination would be to do so, likewise with 
>> X-MMS-Message-Class.
> 
> I'd be fine with changing the text to say "MAY drop" 
> X-Mms-Message-ID and X-Mms-Message-Class, which would make them the 
> same as the other X-Mms-* headers.
> 
> 
Are there any problems with mapping them to MMS-* that I've 
overlooked?

It would seem to be a change that's likely to either leave technical 
problems the same, or lower them, but not raise them.

I don't see how it would alter the complexity of an implementation to 
rename the headers, nor do I see how it could cause any technical 
problems. I do see some slim chance of interoperability problems by 
retaining the "X-" prefix, however.

>>  My inclination would also be to drop the references to 
>> X-Priority. While there's no point in pretending it doesn't exist, 
>> the Importance header is the standard one. I'd see no problem in 

I think that would improve the specification, and my impression is 
that it would satisfy Mark, John, etc, on this point at least.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 15 Jun 2005 21:56:13 +0100

On Wed Jun 15 20:31:06 2005, Ted Hardie wrote:
>> A null transformation of a datum by the gateway is permissible 
>> only when that datum is identical with identical semantics in 
>> both.  In Internet mail, X-* headers have the semantics of 
>> "user-defined field".  They therefore can not be used to represent 
>> MMS headers which have different sematics.
>> 
>> 
> But is this a null transformation?  The view of X- headers in the 
> two systems is
You appear to be agreeing that the semantics were changed, which is, 
I think, Mark's point.

> headers (brightmail poetry, for example).  

None are defined by a standards-track IETF document, in as much as 
I'm aware.

I believe Mark was referring, by "user-defined field", to section 
4.7.5 of RFC822, which uses this term. (Admittedly, it's actually 
"user-defined-field[s]", but I'm willing to forgive Mark his missing 
hyphen.) I don't think he intended to suggest that all X-* headers 
were defined by individual users of network mail, even if that's the 
language used elswhere in that section, but merely that from a 
standards compliance perspective, they can be.

> Why are OMA-defined headers
> different here?

They're different because they don't exist. To the best of my very 
limited knowledge of the OMA, they have not defined any Internet 
message header fields at all.

Assuming you're referring to the X-MMS-* fields, however, those are 
different because they're not defined by the OMA, but by the IETF, 
and, in particular, this working group.

Dave.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 15 Jun 2005 16:17:15 -0500

On 6/14/05 at 5:00 PM -0700, Mark Crispin wrote:

>"protected set of names" for "user-defined fields".

Just for information: The reason 2822 is silent on the matter is 
because the DRUMS working group could not come to consensus on 
whether X-* header fields (a) are good for non-standardizable 
experimental purposes and should be encouraged or (b) should never be 
used because of transition costs and the possibility of leakage in 
non-experimental contexts. Nobody thought that X-* names should ever 
be standardized. (And I will deftly avoid the question that is being 
appealed, whether they should appear in a standards track document at 
all.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Jun 2005 14:37:51 -0700

At 8:52 PM +0100 6/15/05, Dave Cridland wrote:

>> X-Mms-Message-ID and X-Mms-Message-Class, which would make them 
>> the same as the other X-Mms-* headers.
>>
>  Are there any problems with mapping them to MMS-* that I've overlooked?

I am concerned that doing so will lead to more problems than just 
dropping them.  I could be wrong, of course.  But it seems to me that 
if we say to drop them, what will likely happen in reality is that a 
lot of implementations will leave them alone.  If we say to map 
X-Mms-Message-Class to Mms-X-Mms-Message-Class, in reality some 
implementations will do so, some will drop them, some will leave them 
in, and some will do both, and probably manage to change the value of 
one of the two nearly identical headers.  I suspect that will cause 
more problems should such messages make it through the Internet and 
into another MMS system.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Squad Helps Dog Bite Victim
--Newspaper headline

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Jun 2005 11:35:54 -0700

>You appear to be agreeing that the semantics were changed, which is, 

I am agreeing that the semantics on the two sides of the gateway are different.
What I'm asking a question about is whether Mark (or others) feel that
a transformation to something that is semantically null is different from
others.  I guess I'm first asking if folks believe that the transformation
is to something that is semantically null, and then, if they do, whether
that sort of transformation should be a special case?

Speaking without any hats on,
				Ted

---

From: Dave Cridland <[email-masked]>
Date: Thu, 16 Jun 2005 23:25:58 +0100

> that sort of transformation should be a special case?

 From where I'm sitting, a transformation to semantically null ought 
to be identical - semantically, that is - with discarding the 
information. I'm not too concerned about that, although discarding 
information without discarding octets does seem wasteful.

However, if you're accepting that such a transformation is occuring, 
then you must admit the reverse sounds quite worrying. It means 
you're mandating that gateways should take a bunch of octets that are 
semantically null, and imbue them with semantics.

Now, I appreciate that anyone can invent X-* headers, and these are 
well known to work fine in practise, but in most cases, the semantics 
are reapplied by a human (X-Mailer), a tightly coupled system 
(MTA/SIEVE reading SpamAssassin headers), or else the octets are 
chosen so as to minimize the chances of inadvertantly applying 
semantics to the wrong octets (Brightmail poetry).

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 17 Jun 2005 09:52:48 -0700

At 12:52 PM -0700 6/13/05, Dave Crocker wrote:

>  the IETF history is to have the
>  cognizant AD not be a direct contributor to the working group effort.

I can see how there might be a risk that other members or the chairs 
would place improper emphasis or consideration on technical comments 
made in a capacity as a WG member by the area adviser.  But in my 
experience, I don't think such comments have been that rare, and I'm 
not sure they've been actually a problem.  I think the same issue 
applies to the chairs as well.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
DEFINITION: Computer -- A device designed to speed and automate errors.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 13 Jun 2005 15:10:32 -0700 (Pacific Daylight Time)

Ted -

For me, the problem in this case is that you appear to be wearing your AD 
hat when you disagreed with my post regarding the X- prefix for MMS 
headers.  I felt very much like you were an AD ruling against me, rather 
than a mere WG participant.

As far as I can tell, other individuals have expressed the same objections 
to using the X- prefix for MMS headers; and (also AFAICT) you are the only 
individual who has expressed support for using the X- prefix.

But you're the AD, which makes it much harder to argue against.

-- Mark --

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Jun 2005 16:34:32 -0700

At 3:10 PM -0700 6/13/05, Mark Crispin wrote:
>Ted -
>
>For me, the problem in this case is that you appear to be wearing 
>your AD hat when you disagreed with my post regarding the X- prefix 
>for MMS headers.  I felt very much like you were an AD ruling 
>against me, rather than a mere WG participant.
>
>As far as I can tell, other individuals have expressed the same 
>objections to using the X- prefix for MMS headers; and (also AFAICT) 
>you are the only individual who has expressed support for using the 
>X- prefix.
>

I don't think you're doing too poorly :).  But smileys aside, the "speaking
as a technical contributor" and "my personal opinion" are common ways
people say "not wearing AD hat".  If you would like me to add Rob Austein's
<hats=off>, I can certainly do so.
			Ted