Subject: [apps-discuss] Status of the malformed mail BCP

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Aug 2011 09:10:38 -0700

Hi all,

Based on the list discussion about this draft, Barry and I approached IANA in Quebec City to talk about our options.  Someone had suggested the idea of doing a registry of malformations and their corresponding handling advice rather than updating an RFC whenever the list changes.

IANA says they can indeed handle such a thing.  We would need to do the usual registry creation procedures including specifying what the fields are and the rules for making changes, and then give them some guidance about how we'd like it to be presented.

So I think my next step is to convert the existing document into exactly that.  Since the main objection to doing it as an RFC is the idea that it might need to be changed often, perhaps we should go with Expert Review instead of one of the rules that says a specification has to exist.  Any comments on that point?

-MSK

---

From: SM <[email-masked]>
Date: Wed, 10 Aug 2011 14:48:24 -0700

Hi Murray,
At 09:10 10-08-2011, Murray S. Kucherawy wrote:
>Based on the list discussion about this draft, Barry and I 
>approached IANA in Quebec City to talk about our options.  Someone 
>had suggested the idea of doing a registry of malformations and 
>their corresponding handling advice rather than updating an RFC 
>whenever the list changes.

IANA makes unique assignments and maintains registries for the 
currently assigned values.  A malformation does not require such an assignment.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Aug 2011 14:55:55 -0700

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Wednesday, August 10, 2011 2:48 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [apps-discuss] Status of the malformed mail BCP
> 

On the contrary, it seems IANA was willing to create this kind of registry for us.

I suppose you could think of it as advice (values) assigned to malformations (keys).

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Aug 2011 08:08:25 -0400

> On the contrary, it seems IANA was willing to create this kind of registry for us.

Of course it is "willing": IANA's job is to execute the IETF consensus.
It still does not mean that such a registry would be a good idea.

Personally I would see a wiki as more appropriate.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 11 Aug 2011 15:13:53 +0200

On 11 August 2011 14:08, Simon Perreault wrote:

> IANA's job is to execute the IETF consensus. It still does not mean
> that such a registry would be a good idea.  Personally I would see
> a wiki as more appropriate.

An "expert review wiki" can be a very good idea, I'd love to test it
for some topic (if it is MediaWiki, otherwise I'm not sure).  And it
could be hosted by IANA with an apparently "official" URI if they are
still willing:  MediaWiki administration requires some special skills,
mainly the "willingness" to update the installation at least once per
year, and to care about its i18n features with templates, extensions,
and other technical details.

For a "malformed mail" registry (or Wiki) "apparently official" and
"simple to understand" are both important, when mail administrators
are forced to prove their point in a discussion about legal issues.

-Frank

---

From: Peter Koch <[email-masked]>
Date: Thu, 11 Aug 2011 15:38:23 +0200

> IANA says they can indeed handle such a thing.  We would need to do the usual registry creation procedures including specifying what the fields are and the rules for making changes, and then give t…

that IANA is technically capable or "willing" to do this does not
necessarily mean it is in line with IETF processes.  A registry
is not just "a collection of stuff" but would usually exist
for protocol parameters(!) to be uniquely identified.  I have a hard time
seeing that violations of a protocol spec qualify here.

> So I think my next step is to convert the existing document into exactly that.  Since the main objection to doing it as an RFC is the idea that it might need to be changed often, perhaps we should…

This is so much Monty Python that i start to love it. Assume we have Expert
Review for this registry. What if a candidate brokenness fails the
review process - can the implementor enhance their misimplementation to
have it recognized (and eventually registered) as a reviewed protocol violation?

-Peter

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Aug 2011 09:48:17 -0400

Hi Frank,

> are forced to prove their point in a discussion about legal issues.

I've actually thought that every RFC should have an associated (expert 
review) wiki associated with it. Then implementors could post their own 
experiences, notes, issues etc there plus it could auto-link to rfc errata 
and other related stuff. Of course that could mean a lot of work for expert 
reviewers - maybe there should be two pages - one expert review, the other 
public?

-- 
Cyrus Daboo

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Aug 2011 10:09:10 -0400

On Wed, Aug 10, 2011 at 09:10:38AM -0700, Murray S. Kucherawy wrote:

> So I think my next step is to convert the existing document into
> exactly that.  Since the main objection to doing it as an RFC is the
> idea that it might need to be changed often, perhaps we should go
> with Expert Review instead of one of the rules that says a
> specification has to exist.  Any comments on that point?

I think this is stretching past the point of pragmatism.

The proposal, so far, is a sort of extreme case of being liberal in
what one accepts (and what one does thereafter, of course).  I have to
agree with Peter's detection of slight absurdity here, but I also
question whether it would be possible to select an appropriate expert.
Who is more expert in not conforming to the existing protocol
documents than the person who is so nonconforming?  And if there is
nobody, then the correct expert to appoint in each case would be the
implementer of the nonconforming implementation, who would perform the
review and approve the registry entry.  Therefore, assigning the
registry entry on detection of nonconformance would be correct, and no
expert is needed. 

At that point, of course, the problem becomes that you need a stable
reference for the way the nonconformance works, and so you need a
specification anyway.  So "specification required" is correct, I
think.

(The entire passage above, however, could as easily be construed as a
reductio argument against such a registry at all.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 12 Aug 2011 15:15:25 -0400

Two comments:

On Aug 10, 2011, at 1:49 AM, Frank Ellermann wrote:

> Just in case, I think "line too long" can only happen in <obs-body> (if
> at all), otherwise this could be considered as "malformed wrt RFC 5322".

I think you used "can" where "should" is more accurate.  Mimecast recently received an email message with over 7 megabytes in the Message-ID header field.  We decided not to deliver it, suspecting that it would only cause problems downstream as well.  But perhaps we should have replaced or eliminated the Message-ID and then passed it on?  There is no received wisdom here.

On Aug 11, 2011, at 9:48 AM, Cyrus Daboo wrote:

> I've actually thought that every RFC should have an associated (expert review) wiki associated with it. Then implementors could post their own experiences, notes, issues etc there plus it could auto-link to rfc errata and other related stuff. Of course that could mean a lot of work for expert reviewers - maybe there should be two pages - one expert review, the other public?

I really like this idea.  If this were in place, we wouldn't be discussing a malformed mail BCP, we'd just be updating the wiki entries for RFCs 5321/5322.