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?
________________________________
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Fri 07/12/2007 8:35 AM
To: Eric Burger; ietf(_at_)ietf(_dot_)org
Subject: Re: Revising full standards
--On Thursday, 06 December, 2007 19:33 -0800 Eric Burger
<eburger(_at_)bea(_dot_)com> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf