ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>> Make it crystal clear, right up front, how you go about to
>> implement this, and leave the technical details and dry, formal
>> specifications, to some other part of the document."
>
> Very nicely put. This is the main thing I think is wrong with the document.
Nicely put, but I'm not sure I know what it translates into. No doubt I'm
just having some sort of allergy-induced fuzzi-headedness, but I am not
immediately retrieving examples from other specifications that help me
understand what this suggestion actually should look like in practice.
Just off the top of my head, the various Sieve documents are laden with Sieve
code examples that I find to be extremely helpful when implementing things.
The MIME specifications include step-by-step instructions for performing
encoding and decoding. Again, speaking as an implementors, these are
incredibly helpful.
RFC 2821 contains numerous example status responses. RFC 2822 contains a
sample message.
Really, now that I go and look the list of examples of RFCs doing this sort of
thing is pretty darned long. IMAP used to be something of a holdout, I believe,
but this has changed in recent versions. (And I disagree with Mark Crispin's
assessment that this was a mistake.)
In case that sounds like unfriendly resistance (or even friendly resistance)
please understand it isn't: I'm always in favor of adding text that improves
clarity and/or improves pedagogy. In this case, I think I have a fuzzy
understanding of the basic desire, but I'm not seeing how to turn that into
words. I don't see how the Intro on its own, or the Model introduction
paragraph on its own, or the Operation section on its own fail to satisfy the
goal.
And no, I'm not seeking to debate or defend them. I'm looking for something
concrete to help me understand what needs adding. (In a feeble attempt to try
to be more helpful in asking for help I'll say that I'm not worried about
careful wording; anything roughly along the lines desired would be fine. we
can word-smith it later.)
> And this is what I was getting at when I said that I'm concerned that the
> labelling is insufficiently unique in format. Mind you, I'm not proposing a
> change here, merely expressing concern.
Here I am certain I *do* understand the concern. And it's always a valid
concern to raise about a syntax.
Um, not really. Most of the times when we define a new syntax it fits into an
entirely new niche somewhere and we know when to use it from the context.
Accordingly, the criteria for syntax selection are usually simplicity, ease of
evaluation, ease of production, extensibility, and so on. The ability to "
reliably pick the syntax out of a lineup" is rarely on the list.
Unflagged overlay syntaxes like this are the case where distinguishability from
the background is a concern, and such cases are comparatively rare. In fact
aside from the obvious example of RFC 2047 I'm having trouble thinking of other
examples in the protocols we normally deal with. (OK, there was some use of
overlay syntax in the original MIME RFCs as well as in RFC 822, but this was a
structural artefact of the ways in which those documents were written, not a
requirement imposed by trying to extend an existing protocol structure. And it
is telling to note that this usage has been eliminated from more recent
versions of those specifications without changing protocol syntax or
semantics.)
The problem is that we can't do much with it unless someone documents
deficiencies in the current syntax, with respect to requirements that we agree
need to be satisfied. While the current syntax has some evolution -- ie,
learning -- that produced it, I don't think any of us is religious about this
sort of detail, other than wanting changes to have a clear motivation, clear
benefit, and the usual consensus.
Really. If someone wants the current syntax changed, please do propose it,
explaining why it is needed.
Again, I'm not proposing a change. I'm merely a little worried that the syntax
is insufficiently unique and I'm wondering if others are also concerned. I
already gabe an example of another existing, albeit nonstandard, overlay syntax
for local parts it conflicts with: SRS. But this one is easy to address if we
think it is worth it: Prohibit use of SRSn as a registered tag. All it would
take is a single sentence in the registration criteria.
Now, looking at RFC 2047, I think we actually went a little too far to try and
avoid conflicts where stuff not intended to be seen as an encoded-word got
taken as one. The result is the syntax is a little too complex and there have
been any number of implementation problems. (I note in passing that RFC 2047
has been criticized from not providing explicit step by step procedures for
dealing with encoded words.) So I'm definitely not proposing that we adopt =?
and ?= or something similar as part of this.
In any case, if nobody else sees a problem here then I think it is fine to move
forward with the current syntax.
Ned