John,
Stating that a proposal has been discussed before is a standard strategy of agenda denial. Every time the issue is raised the reason for making no change is either 'we have not done things that way in the past' or 'this has been discussed before'. We go round in circles without discussing the substance of the problem, the result reinforces the failed status-quo.
Maybe an amateur approach to semiotics is as counter-productive as the 'amateur lawyering' you detest when the points raised conflict with your own point of view. The STD series has been a failure by any standard. As a former experimental scientist I beleive that when you try something and it fails you consider the possibility something else might be better.
I did not want to take the bait you left Tuesday morning because I wanted to concentrate on the substance rather than engage in a snark-fest. On that occasion you continued. Given that you have identified the fact that there is a problem, let us leave asside the snark and address the actual issues.
The proposal I originally made had two levels:
IETF-SMTP for the mail protocol standard
IETF-SMTP-YYYY for a particular version of the standard
In some cases one wishes to refer to a particular version, in others not. In the example I gave the distinction between the versions was relevant. In other cases it is not. For example a Web Service might well state that it is layered on IETF-HTTP might not speficy the version of HTTP.
The reason for specifying IETF-SMTP rather than mere SMTP is twofold:
1) We need to clearly distinguish a protocol standard from a protocol. The term SMTP does not carry the intended semiotics.
2) The choice of IETF vs some other label (e.g. STD) is both the fact that STD is unacceptable and the fact that there are multiple competing standards bodies out there and the IETF can benefit from the branding leverage.
One of the experimental results we might deduce from the relative success of IETF application protocols over their OSI competitors is that text based mnemonic labels are more successful than pure numbers. From: and To: make for a much more successful protocol than their ASN.1 equivalents.
Steve Crocker's original proposal for the RFC series was close to the spirit of a modern Wiki. The numbering scheme was proposed precisely because the identifiers should not matter. We are now trying to influence the direction of the worlds most successful communication infrastructure with over a billion users. The manner in which we communicate our message has a greater effect than the message itself.
The vast majority of the people we need to influence have no knowledge of or concern for IETF traditions. We have to communicate in ways that they are receptive to.
The bigger problem is that for whatever reason, Vint, Jon and co did not provide an effective mechanism for changing the opperating practices of the IETF. We can accrete new traditions but we are unable to shed or modify old ones, no matter how much make-work this results in.
I can write up my proposal as an Internet draft, but what is the process for reviewing or progressing it?
--On Thursday, 06 December, 2007 19:33 -0800 Eric Burger
<eburger@xxxxxxx> wrote:
> 61 of the 67 have nmemonic identifiers, like SMTP and MAIL. I
> would also lean toward IETF-SMTP-2008.and resolved in the past does not excuse you
A proposal from a family that, as you might recall, has been
discussed many times and gone nowhere. Of course, as soon as
one attaches a date, one has solved a problem different from
"stable identifier for the current version of the standard".
And, of course, unless these can identify other than Full
Standards, they don't solve any of the STD problem that concerns
me.
And, FWIW, if you think "MAIL" is the identifier for some
protocol or set of protocols, you have illustrated another
problem. :-)
> I actually have mixed feelings about interop. Part of me says
> that going to Internet Standard is mostly about removing
> cruft. However, in theory, a full regression test is not over
> the top. I still vote for ad hoc. Let the IESG or, since there
> are so few, the IAB, decide if this particular revision of
> that protocol warrants a full redo of the interoperability
> report.
This works for me as long as we solve the STD problem in some
way. And simply throwing them away so they aren't misleading
would fall into the class of options I'd consider a solution.
I'd like to hear from others. If no one else cares, I'll just
generate an I-D/ proposal to abolish STDs on the grounds that
the 'running code' doesn't work.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf