On 15 nov 2005, at 16.43, Dondeti, Lakshminath wrote:Hi Eliot, The most recent number of nomcom eligible folks is 849, please see https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=446. 20 people out of that isn't all that high. I think I might easily find 10 like-minded people; but
On Wed, Nov 16, 2005 at 12:29:51PM -0800, Bill Fenner wrote:
Straight revision control systems aren't actually that good for XML
that's been edited in an XML editor, since they tend to pretty-print
the XML when saving, and people using 2 different editors could end up
creating diffs on every
On Wed, Nov 16, 2005 at 09:45:00AM -0800, Ted Faber wrote:
WRT revision control software on I-Ds, I think it's an excellent idea,
but authors should use whatever they agree on. IMHO, the IETF doesn't
need to provide a system. CVS vs. RCS vs. subversion vs. $DIETY knows
what is too much of
Gray, Eric wrote:
Stewart,
While an interesting turn of phrase, hair shirt approach
is hardly an accurate analogy, nor is it particularly apt to compare
presentation materials (where there's a real live person in front
of you to answer questions) with specifications (where there
Eric,
This discussion is appropriate on this list, that is
not my point. I would have stated I think this is
off topic for this list if it were.
I am just so frustrated that good technical people
spend (I perceive it as waste, but that is subjective
and not fair) their time on these sort of
Yaakov Stein wrote:
It's good that protocols needing more than 72 ASCII characters are
forbidden.
Just imagine what elegantly simple protocols we would have
if we required the descriptions to be in Morse code.
Good idea.
It's a better approach to enforce much simpler protocols.
This is the nth time we've had this discussion RE ASCII art in IETF, but
without a process for process change, no change could be made even if we
all agreed, which we never do of course. While the discussion may be
enlightening and entertaining, in the end it does nothing but waste
cycles, there
If we want to enforce simpler, more accurate design the best way to do
this would be to require a formal proof of correctness before accepting
a specification.
Requiring people to use 1960s technology is not a way to achieve
simplicity.
-Original Message-
From: [EMAIL PROTECTED]
Yaakov,
Funny. Ha ha.
The big distinction is that very few people can read
Morse code. Can you?
--
Eric
-- -Original Message-
-- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-- On Behalf Of Yaakov Stein
-- Sent: Thursday, November 17, 2005 1:48 AM
-- To:
-- -Original Message-
-- From: Stewart Bryant [mailto:[EMAIL PROTECTED]
-- Sent: Thursday, November 17, 2005 5:01 AM
-- To: Gray, Eric
-- Cc: ietf@ietf.org; Lars-Erik Jonsson (LU/EAB)
-- Subject: Re: Diagrams (Was RFCs should be distributed in XML)
--
--- [SNIP] ---
--
-- I
Phillip,
I spent a large fraction of my professional life in pursuit of this
alluring and seemingly simple goal. Here's a small challenge: Take
*any* IETF protocol and write down the formal specification. Never
mind the proof of correctness; that can come later. (And with it an
There is a way, develop a highly targetted formalism for the specific
problem.
This is hard to apply to existing specs because they tend to be
inconsistent. If you are required to apply a formalism you have to be
much more consistent in your design approach.
I did this for the finite state
Well, even if you choose your formalism first and then use that to
guide the development and specification of the protocols, the
challenge still stands. The operative word in your description is
portions. Does the technique cover enough of the protocol to be
useful and does it wind up
Steve Crocker wrote:
Just something simple and instructive to make your point.
And in light of the other issues being discussed, don't
feel constrained to use ASCII. Use any notation and tools
you like.
Do you expect Phil's reply before 2007 ? There were some
really nice SDL-tools about
The description was sufficiently complete to allow running code to be
compiled from the formal specification.
It certainly does save time when used by someone who has the necessary
experience to work at a very high level of abstraction. The problem is
that it is very hard to persuade others to
On Thu, Nov 17, 2005 at 09:25:03AM +0100, Juergen Schoenwaelder wrote:
On Wed, Nov 16, 2005 at 09:45:00AM -0800, Ted Faber wrote:
WRT revision control software on I-Ds, I think it's an excellent idea,
but authors should use whatever they agree on. IMHO, the IETF doesn't
need to provide
*
* P.S. Some good arguments have already been made on both sides of the
* ASCII art issue. I, like many others, use Word, etc. editors capable of
* sophisticated graphics, and have to struggle to convert to ASCII art in
* I-Ds. IMO this is a ridiculous waste of time and loss of
I remember that when the ITU-T was pushing for more use of formal tools in
its IETF cooperation, around the London timeframe (2001), one person wrote
a formal definition of OSPF in one of their formalisms.
I don't remember if he found any problems in the spec based on that
exercise, but
We do have a process for process change. We can approve a BCP using
the procedure outlined in RFC 2026.
When we can get a strong consensus behind a process change, that
procedure works reasonably well.
There are other cases where it doesn't work well. Some of us think
that's OK; some of us
Like live polio vaccine there tends to be a prophilactic effect that has
wider application.
Although formal methods were not used in the design of Java and were not
part of the design of C# as far as I am aware, both languages were
designed after the field of software language development had
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Braden
*
* P.S. Some good arguments have already been made on both
sides of the
* ASCII art issue. I, like many others, use Word, etc.
editors capable of
* sophisticated graphics, and have to struggle to
In OASIS the de facto document markup during the preparation of the
documents is Word. The principle reason for this is that Word allows for
changes to the document to be highlighted.
The ability to see the differences to the document is critical if you
want people to read it thoroughly more than
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, I do not think that you really care about
Hallam-Baker, accessibility. If you did you would understand why
Hallam-Baker, the idea of putting ASCII art through a text to
Hallam-Baker, speech interface
Sam,
I agree with you on the fact that text should stand alone.
People who think that it is not possible to describe a figure
sufficiently well enough for it to be accurately understood
without seeing it should try attending more conference calls
where they are at the wrong (as in
We do have a process for process change. We can approve a BCP using
the procedure outlined in RFC 2026.
When we can get a strong consensus behind a process change, that
procedure works reasonably well.
There are other cases where it doesn't work well. Some of us think
that's OK; some of us
Phillip,
And, with text versions, you can either require authors to
outline the relevant changes (who really cares that page numbers
have changed from one version to the next?) - as many Working
Groups do - or you de-()roff the text and run diff to see what
the detailed changes were.
At 4:51 PM -0500 11/17/05, Sam Hartman wrote:
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, I do not think that you really care about
Hallam-Baker, accessibility. If you did you would understand why
Hallam-Baker, the idea of putting ASCII art
I've been quiet through this discussion and its various offsprings, but
now I just have to say very well done Paul. It doesn't matter what you
use for your diagrams if your prose is poorly written.
Paul Hoffman wrote:
At 4:51 PM -0500 11/17/05, Sam Hartman wrote:
Hallam-Baker, ==
At 01:43 PM 11/17/2005, Hallam-Baker, Phillip wrote:
In OASIS the de facto document markup during the preparation of the
documents is Word. The principle reason for this is that Word allows for
changes to the document to be highlighted.
The ability to see the differences to the document is
On Thursday, November 17, 2005 03:22:58 PM -0800 Lee Mahan
[EMAIL PROTECTED] wrote:
I've been quiet through this discussion and its various offsprings, but
now I just have to say very well done Paul. It doesn't matter what you
use for your diagrams if your prose is poorly written.
Nor,
Hallam-Baker, Phillip wrote:
In OASIS the de facto document markup during the preparation of the
documents is Word. The principle reason for this is that Word allows for
changes to the document to be highlighted.
I tried and found that, if I modify figures there is no highlightning.
Even if
31 matches
Mail list logo
