Subject: RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]

From: "Gray, Eric" <[email-masked]>
Date: Thu, 5 Jan 2006 12:25:23 -0500

Brian,

	I think it is somewhat unfair to say that we have
not tried the steps you outline below.  Where we run into 
trouble is when different sets of people disagree as to
which of the steps we are currently working on.

	Quite frankly, I believe we can address the second
step (which of the requirements are not met today?) with 
a firm "none."

	This is - IMO - the basis for the apparent stodgy
resistance to change.

--
Eric 

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Brian E Carpenter
--> Sent: Thursday, January 05, 2006 7:36 AM
--> To: Harald Tveit Alvestrand
--> Cc: [email-masked]
--> Subject: Engineering our way out of a brown paper bag [Re: 
--> Consensus based on reading tea leaves]
--> 
--> Harald Tveit Alvestrand wrote:
--> > 
--> > 
--> > --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein 
--> > <[email-masked]> wrote:
--> > 
--> >> The only thing I am sure about is
--> >> that
--> >> consensus on this list is for keeping everything exactly 
--> as it is.
--> > 
--> > 
--> > I'm pretty sure there's no such consensus.
--> > 
--> > I do, however, see a rather strong 
--> consensus-of-the-speakers against 
--> > using MS-Word document format for anything "official".
--> 
--> I think we need to tackle this whole issue, if we do decide to
--> tackle it, in a much more systematic way.
--> 
--> - what are our functional requirements?
--> - which of them are not met today?
--> - what are the possible solutions, and what is their practical
-->    and operational cost?
--> - which, if any, solutions should we adopt, on what timescale?
--> 
--> I believe that if we took a systematic approach like that, the issue
--> of how we determine consensus would be broken into enough small
--> steps that it really wouldn't be an issue.
--> 
-->      Brian
--> 
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Jan 2006 18:35:15 +0100

I agree.  As usual we seem to be stuck in an infinite loop on this
mailing list with the cycle being somewhere between 6 months and 3 years.

Eliot

---

From: "Brett Thorson" <[email-masked]>
Date: Thu, 5 Jan 2006 13:16:25 -0500 (EST)

I wonder if that time frame represents the amount of critical mass
turnover for these topics to be refreshed, but previous discussion
forgotten.

I don't know if there is something that would fulfill this roll, but from
40 feet back, here is a suggestion.

A bulletin board (Not BBS, but like an old cork one).

Take what Brian said, that we need to look at this in sections.  True.
Take what Eric said, we are doing that, but different people at different
times at different sections.  True.

Wouldn't it be nice to compartmentalize some of these systematic
functions, but still keep them as neighbors so that if someone wants to
talk about _requirements_, you step over and look at that section, and all
the notes that people have stuck to the board.  If someone wants to look
at _solutions_ they look there.  If they just want an overview, they
glance at the whole thing.

If people think an idea is not great, it gets stuck to the bottom, if it
is well liked by many, then it bubbles up to the top (allowing many to
bubble up or down).  The reasons could be discussed on the list, but the
result might end up on the board.

What is nice is that if we just shrug our shoulders and walk away from it,
we can come back to it in .5-3 years time and look back at this simple
"cork board" rather than spilling through mounds of mail archives.

I think (after watching the IETF for a while) that a fair amount of time
is spent rehashing good ideas (and bad ones).  Maybe a "cork board" that a
newcomer could come up to, see the note, see the notes about the note
would be useful.  (Think persistance of knowledge in the new-comers
orientation information presented at each IETF).

Again, I'm just tossing this out there as a brainstorm idea.  I think the
problem (ID-Format) is real.  I think it is solvable.  I think we have too
many great brains jumping around the systematic process of solving it,
thus spending time on thought swapping and bringing newcomers up to speed.

In other words, an e-mail list might not be the best way to solve the
problem, and an e-mail archive might not be the best way to keep the
summary knowledge around and accessible for newcomers to the task.

--Brett

-- 
Please note that my e-mail address has changed.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Jan 2006 18:19:24 +0000

>step (which of the requirements are not met today?) with 

That is not true, we don't address the need to include diagrams.

- Stewart.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Jan 2006 18:21:34 +0000

>mailing list with the cycle being somewhere between 6 months and 3 years.
The fact that we keep coming back to this topic may be a message in itself!

- Stewart

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Jan 2006 19:34:11 +0100

> The fact that we keep coming back to this topic may be a message in
It reminds me of a "pick your favorite" special interest lobby who
continually wants change, even if the rest of us don't.  Either
eventually we get convinced or we don't, but in the process we sure get
an earful.

Eliot

---

From: John Levine <[email-masked]>
Date: 5 Jan 2006 19:31:06 -0000

> 	Quite frankly, I believe we can address the second step (which
> of the requirements are not met today?) with a firm "none."

At some level that's clearly true, since RFCs are emerging at a brisk
clip.

I've seen two different sets of concerns.

One is that ASCII doesn't permit adequately beautiful pictures.  If
that's the problem to be solved, it seems to me that a straightforward
solution would be to allow authors to submit image files along with
the ASCII text.  I'd suggest requiring that the image format be GIF,
since it's simple, stable, well documented, widely supported in both
freeware and commercial software, and the patents have expired.  (Or
maybe PNG, any stable public format will do.)

The other is that the editorial process is more tedious than it needs
to be, because RFCs have a mandatory structure that plain ASCII
doesn't express.  RFC 2629 or 2629bis captures the structure while
being well supported in free and commercial software and, in a pinch,
legible without tools since it's ASCII underneath.

This confirms to me that what we need to decide is what the problem
is, since the solutions to each problem are straighforward.

R's,
John

PS: I gather that clay is quite stable if properly fired, and is
probably less subject to chipping and acid rain pitting than marble.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jan 2006 12:22:38 -0800

On Jan 5, 2006, at 11:31 AM, John Levine wrote:

>> Quite frankly, I believe we can address the second step (which of  
>> the requirements are not met today?) with a firm "none."
>
> that's the problem to be solved, it seems to me that a  
> straightforward solution would be to allow authors to submit image  
> files along with the ASCII text.  I'd suggest requiring that the  
> image format be GIF, since it's simple, stable, well documented,  
> widely supported in both freeware and commercial software, and the  
> patents have expired.  (Or maybe PNG, any stable public format will  
> do.)

A minor problem with independent graphic files is they are difficult  
to manage.  A graphic image has also become a vehicle for Trojans, as  
file extensions often do not take precedence within rendering  
engines.  This would impose a new risk for the editor.  An interim  
solution could be a drawing application (or a regular editor) that  
uses Unicode "Box Drawing" characters rather than ACSII hyphens,  
under-score, plus symbols, greater-than, less-than, and vertical  
bars.  For these to provide a clean output, the line spacing would  
need to be controlled for a clean look.  This can be done using HTML  
and PDF outputs.

> The other is that the editorial process is more tedious than it  
> needs to be, because RFCs have a mandatory structure that plain  
> ASCII doesn't express.  RFC 2629 or 2629bis captures the structure  
> while being well supported in free and commercial software and, in  
> a pinch, legible without tools since it's ASCII underneath.

These tools can already utilize the "Box Drawing" characters, so a  
utillity to assist with the creation of the box drawings would make  
this less painful.  The utility could also add the needed XML wrapper  
to make this an easy cut and paste.  If desired, these characters  
could be translated back into the ASCII equivalent for the ASCII  
version.  It would also seem that bibliography and author names could  
also include a Unicode element used by the HTML and PDF outputs, but  
then not the ASCII versions.  The alternative elements for titles and  
authors would be assuming a desire to retain the ASCII only version.   
If the ASCII version is not retained, then the effort would be even  
more straight forward.

-Doug