> > However, I'm arguing that > > there is scope on this particular point for concluding that there is > > a *technical* issue (a source of confusion, i.e. a lack of clarity). > If would be fascinating to see someone attempt to defend such a claim > seriously and with pragmatic substance, rather than detached theory. > That is, to try to prove the claim with facts. Exactly so. Isn't it sort of the point of that whole "running code" thing to prefer operational experience to finespun theorizing? And in that vein, I have a few small data points to offer. I'm the author or coauthor of quite a number of RFCs as well as various other documents, and up until recently I have not only used whatever domain names I felt like in these documents, I've also used actual valid email addresses. In particular, I've used a lot of addresses in the innosoft.com domain, some valid, others invalid, as well as the domain itself. I also served as postmaster for the domain for 15 years or so, which gives me a pretty good idea of the consequence of its usage. Based on this experience, I've found that domain usage in documents basically breaks down into three categories: (1) Example objects, dialogs, and transactions (2) Test objects and vectors. (3) Sample configuration information Despite having used innosoft.com extensively in example objects and dialogs, including but not limited to widely implemented full standards like RFC 2920 and even more widely implemented draft standards like RFC 2049, I cannot recall a single instance where this has caused a noticeable problem or generated a complaint. This was true even before email became inundated with spam, and now that spam is so prevalent it is difficult for me to imagine a scenario where type (1) usage in a specification would actually matter. Test objects and vectors have been more of an issue, but only slightly. The example I have here is the set of MIME messages Nathaniel Borenstein assembled back when MIME first came out. This corpus was never published in an RFC but was widely disseminated in tarball form. Quite a number of these messages had my address in a To: or Cc: field, with the result that I used to receive copies of the messages from time to time from various random places performing testing. All things being equal I would have preferred not to have gotten those copies (although in some case it was amusing to see who was testing MIME capabilities), but seeing as the spam I now get in a single day is probably an order of magnitude greater than all the copies of these messages I ever received put together, it is difficult to care very much. Sample configurations are another matter entirely. We made the mistake of using our domain in one or two such examples in product documentation, with the result in one case that we were hit with quite a number of queries. This was sufficiently annoying and we took note and never did that again. My conclusion based on my own experience is that use of "proper" example domains in sample configurations definitely rises to the level of a strong SHOULD. Test objects and vectors warrant a weak SHOULD at most, in the email subcase at least. But random sample email messages and dialogs have been a nonissue and there warrant no special compliance. Just a little data in support of evidence-based engineering. Ned P.S. Based on the ongoing misunderstanding of the situation apparent in several recent postings I feel compelled to reiterate that the appeal is almost entirely about the nature of our process, not about the resolution of domain usage in 2821bis. As for the process part of this, I've been trying very hard to stay away, mostly because i find the fact that it was necessary for John to file this appeal to be so utterly appalling that I don't entirely trust myself to be able to engage in civil discourse about it. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf