RE: Alternative formats for IDs
If you do not know how to do that with Word, there is help to get. Yes, in RFC 3285. 3285 Using Microsoft Word to create Internet Drafts and RFCs. M. Gahrns, T. Hain. May 2002. (Format: TXT=34556 bytes) (Status: INFORMATIONAL) [YJS] Yes of course we all have used that. However, unfortunately there are problems with that route and no-one is supporting it (as XML2RFC is supported). True, this had not been a problem if the output from Word had been consistent. Anyway, Joe Touch has been updating these tools and you can find them at: http://www.isi.edu/touch/tools/ For example, when printing directly from Word (rather than first producing the ASCII and then printing) the margins are all wrong. True, printing directly is a missing feature of the tools provided by RFC 3285. Joe's version fixes this, so you should be happy with his version also for that reason. Also, certain combinations of characters I use in ASCII art cause (for some unknown and undocumented reason) strange unprintable characters to appear in the ASCII version. Probably this is because you have used characters not part of 7-bit ASCII. It is a good idea to always turn off the auto-correct features of Word, otherwise you will probably get strange characters. Rgds, /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Yaakov Stein wrote: However, the text objected to in this case argues that this process should be extended by a process of counting the people who don't publicly participate in the discussion (snip) We proposed gauging interest by a show of hands at a plenary meeting, rather than by the number of yes votes on this list. Yes, even that is not optimal since there are people who prefer working in the terminal room or touring in the evenings, but it certainly seems to be a better way of finding out what MOST IETF participants want than only reading this list. Perhaps we can move past the discussion of what you originally proposed or did not propose. That does not seem very productive. And it must feel frustrating to get criticism for something that you did not propose. FWIW, I believe that what you suggest above for using the plenary is the best way to determine IETF consensus for some IETF-encompassing issues. (With a follow-up on this list of course, but unless that generates hundreds of responses, its unlikely to make a difference to what the room thought. And there should be some preparation in the list prior to the meeting, like announcing that people should read these drafts and that certain questions are going to be asked.) --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
As far as I can tell, Microsoft has no idea what ASCII means. You would
expect that Save As... Text Only would produce clean ASCII from a
pretty Word file, but it does not. Instead, you get a file which
contains various 8-bit encodings of common characters such as curly
quotation marks, en- and em-dashes, bullets and so on, in spite of the
fact that there are perfectly good, and commonly-used ASCII conventions
for all of this stuff (' * -- --- ...). I can't tell you how much time I
spend fixing problems caused by this kind of stupidity. Auto-correct or
not, why can't Word have a simple ASCII-fy feature???
Ole
PS. Speaking about Word 11.2 for the Mac, your mileage may vary.
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 GSM: +1 415-370-4628
E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj
On Thu, 5 Jan 2006, Lars-Erik Jonsson (LU/EAB) wrote:
[ ... ]
Probably this is because you have used characters not part of
7-bit ASCII. It is a good idea to always turn off the auto-correct
features of Word, otherwise you will probably get strange characters.
Rgds,
/L-E
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: ... I have never had a problem opening an old file with an up-to-date version of the SW. The problems arise when you try to do the reverse. That makes sense of course, since if you could do everything with the old version, then no-one would buy the new one. After all, a company with 95% market has to be inventive in order to continue selling. Well, our experiences differ. Let's put philosophical and individual economic issues aside for a moment. Let's also temporarily ignore the observation that many members of our community do their work on operating systems on which the current version of Word is not supported. I continue to consider those issues to be showstoppers, but perhaps the compatibility argument is worth pursuing a bit. I think there are two problems here, plus one raised in a note by Lars-Erik. (1) I have had problems opening and using documents from sufficiently old versions, sometimes as recently as two versions ago. I even know the source of some of those problems. For example, I have never had a problem opening, in a clean and unmodified current version of Word, an old document that uses exactly one template and that one unmodified as if out of the box, contains no macros and no workarounds for obscure bugs, and does not use cross-references or a host of other specialized features. For the record, I don't suggest that any document that uses any of those features runs into trouble, only that a sufficiently complex combination of them do. It has often appeared to me that the machinery that converts from the formats of an older version of Word to a newer one will handle the simple cases well but, especially when the original document is several versions older, there seems to be some tendency for Word to get itself into trouble. And, if the old document contains macros or styles that are already present in the normal document template of the new version but with different definitions for some of the set... my experience has been that occasionally things work without side-effects. For some of these cases, one even has to be careful about what it means to successfully open an older document. For example, there was a considerable period in which a document written in the then-current (not even previous-generation) version of Windows Word could be opened just fine with the then-current version of Mac Word... as long either the Windows version contained no comments or one did not care that they disappeared in the transition. Now, you could reasonably suggest that good document hygiene would argue for avoiding most of those features, or removing them in the old system before trying to move documents to the new one. You would, of course, be correct. But to avoid all of those features eliminates much of the power of Word relative to, e.g., ASCII editors that are available for all platforms at negligible cost. And those extended features, once inserted in a document, are not easy to remove. It is, for example, possible to configure Word 2003 to issue a warning every time one tries to save a document containing change-tracking or comments to a file. But, at least as far as I have been able to discover, there are no warnings for macros, styles, and the like. And, while one can say don't save, there are, as far as I know, no options built into Word for cleanly removing all of that stuff and getting a document into the safest of forward-compatible forms. Similarly, there is a configurable warning when one opens a document with embedded macros. But the effect of run safely is not remove all of those macros forever but disable them in this session. If they are hostile and if, for one reason or another, the macro-removal tool (which I'd lay good odds most users of Word don't even know where to find) won't touch them because of how they are installed (a common case), they just lie around as traps for some future unwary person. (2) If I understood correctly, one of the main arguments you made for Word was its change-tracking and collaboration facilities. I certainly agree about the change-tracking. But, as for collaboration, it seems to me that you cannot simultaneously argue that it is unreasonable to expect version-downgrading to work and also argue that Word provides good and useful support for collaborative work in a heterogeneous community. Again, even putting aside economic and similar constraints, we have no way to get everyone in the community to do an upgrade on the same day. Even Microsoft can't keep the feature sets in current versions of Windows Word and Mac Word identical, if only because their release cycles differ (nor are those versions bug-compatible, of course). Even if we could somehow get around those problems, few people who obtain Word in enterprise settings are permitted to install a newer version ahead of the rest of the enterprise, precisely because of that
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 PROTECTED] 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: bozoproofing the net, was The Value of Reputation
Michael Thomas wrote: Harald Tveit Alvestrand wrote: [] Sigh. Can I suggest that a little exponential backoff on all parts may be appropriate? As one of the authors of the dkim draft, this has been an extremely painful thread to watch. Correct. This is way beyond the point of being productive and beyond the point where busy people will even read 5% of the messages. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
John C Klensin wrote: --On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: ... I have never had a problem opening an old file with an up-to-date version of the SW. The problems arise when you try to do the reverse. That makes sense of course, since if you could do everything with the old version, then no-one would buy the new one. After all, a company with 95% market has to be inventive in order to continue selling. I have had that very same experience, only worse: There was no way of accessing documents from word for OS/2 after somebody had been reading them with winword. Winword cold, but for word for OS/2 they were lost. Only transfering them to CP/M 86 with kermit and processing them with wordstar and then transfering back with kermit again made them workable again. Dont ask what happened to the typesetting. Well, our experiences differ. Let's put philosophical and individual economic issues aside for a moment. Let's also temporarily ignore the observation that many members of our community do their work on operating systems on which the current version of Word is not supported. I continue to consider those issues to be showstoppers, but perhaps the compatibility argument is worth pursuing a bit. I think there are two problems here, plus one raised in a note by Lars-Erik. (1) I have had problems opening and using documents from sufficiently old versions, sometimes as recently as two versions ago. I even know the source of some of those problems. For example, I have never had a problem opening, in a clean and unmodified current version of Word, an old document that uses exactly one template and that one unmodified as if out of the box, contains no macros and no workarounds for obscure bugs, and does not use cross-references or a host of other specialized features. For the record, I don't suggest that any document that uses any of those features runs into trouble, only that a sufficiently complex combination of them do. It has often appeared to me that the machinery that converts from the formats of an older version of Word to a newer one will handle the simple cases well but, especially when the original document is several versions older, there seems to be some tendency for Word to get itself into trouble. And, if the old document contains macros or styles that are already present in the normal document template of the new version but with different definitions for some of the set... my experience has been that occasionally things work without side-effects. For some of these cases, one even has to be careful about what it means to successfully open an older document. For example, there was a considerable period in which a document written in the then-current (not even previous-generation) version of Windows Word could be opened just fine with the then-current version of Mac Word... as long either the Windows version contained no comments or one did not care that they disappeared in the transition. Now, you could reasonably suggest that good document hygiene would argue for avoiding most of those features, or removing them in the old system before trying to move documents to the new one. You would, of course, be correct. But to avoid all of those features eliminates much of the power of Word relative to, e.g., ASCII editors that are available for all platforms at negligible cost. And those extended features, once inserted in a document, are not easy to remove. It is, for example, possible to configure Word 2003 to issue a warning every time one tries to save a document containing change-tracking or comments to a file. But, at least as far as I have been able to discover, there are no warnings for macros, styles, and the like. And, while one can say don't save, there are, as far as I know, no options built into Word for cleanly removing all of that stuff and getting a document into the safest of forward-compatible forms. Similarly, there is a configurable warning when one opens a document with embedded macros. But the effect of run safely is not remove all of those macros forever but disable them in this session. If they are hostile and if, for one reason or another, the macro-removal tool (which I'd lay good odds most users of Word don't even know where to find) won't touch them because of how they are installed (a common case), they just lie around as traps for some future unwary person. (2) If I understood correctly, one of the main arguments you made for Word was its change-tracking and collaboration facilities. I certainly agree about the change-tracking. But, as for collaboration, it seems to me that you cannot simultaneously argue that it is unreasonable to expect version-downgrading to work and also argue that Word provides good and useful support for collaborative work in a heterogeneous community. Again, even putting aside economic and similar constraints, we have no way to get everyone in the community to do an
Re: Alternative formats for IDs
On 01/04/2006 17:09, Julian Reschke wrote: Stephane Bortzmeyer wrote: If we use a XML format, why the very large and complexe (700 pages) OpenDocument and not our RFC 2629? Indeed. Although, at some point of time we'll have also to realize that there most people when they say RFC2629 they really mean RFC2629bis. So, sooner or later, we'll have to start work on a proper spec revision. Best regards, Julian As I understand it, one of the major concerns of the people pushing for alternative formats is a desire to be able to include drawings and diagrams with something other than ASCII art. I don't believe that XML does much to help that. If one is worried about things like including pictures, diagrams, revision marks, etc. then I think looking into something like Open Document Format would make a lot more sense than considering a proprietary format like MS Word. OTOH, if ASCII is good enough, then I guess there's nothing to worry about. I don't have enough IETF experience to have a strong opinion either way. I just think that if alternatives are going to be looked at, then ODF ought to be one of them. Scott Kitterman ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus based on reading tea leaves]
Brian - you've hit on an important point here. It strikes me that the process for defining our own document standards has no fundamental differences from the process for defining any other standard. Why shouldn't this archival document standard be developed and adopted as a Standard in the same way? I've explicitly refrained from contributing any observations from my 15 years of experiences working with IETF docs in vi, emacs, nroff, Word, LaTeX, PDF, ASCII-art diagrams, XML2RFC, dot-matrix printers, etc., as well as experience with Word in CableLabs/DOCSIS specs - because those contributions would not be part of an engineering process like the one you describe, and would be simply more hot air if posted outside of a process. Well, one might say, haven't we tried the IETF process on the archival document format problem in the past? And the document format hasn't changed. Yup, and there are a couple of (not necessarily mutually exclusive) conclusions we might draw: * the current format is the best solution we can devise for our requirements * the IETF engineering process is flawed - Ralph On 1/5/06 7:35 AM, Brian E Carpenter [EMAIL PROTECTED] wrote: Harald Tveit Alvestrand wrote: --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein [EMAIL PROTECTED] 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus based on reading tea leaves]
Brian E Carpenter wrote: Harald Tveit Alvestrand wrote: --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein [EMAIL PROTECTED] 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. I am in favour of any practical method that allows us to progress towards the best tools for the job. My personal end-goal is simple: I want us to be able to use modern graphical techniques in normative text to help me to describe problems and their solutions. There are many other nice-to-have's, but at the end of the day it is the diagrams that are the key missing feature in our document process. The following would be a fine set up steps on the way to determining the way forward. Perhaps my co-authors and I should attempt another draft with this structure. - 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. Maybe. The discussion on the list illustrates the well known problem of determining consensus in the presence of highly vocal members of the IETF community. This, as I recall, is a problem that was discussed some time ago in the Miss Manners talk. However it is separate problem from the issue of document formats and should be addressed as a different work item. - Stewart Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Baby Steps (was RE: Alternative formats for IDs)
Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Thanks, Regards, Jerry From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yaakov Stein Sent: Sunday, January 01, 2006 12:37 AM To: ietf@ietf.org Subject: Alternative formats for IDs Happy new year to everyone. I would like to call your attention to a new ID http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. This ID is the result of discussions here on the general list, and proposes the use of formats other than plain ASCII for IDs and RFCs. In particular, it proposes the allowance of diagrams other than ASCII-art as normative. The authors felt that further discussion on the list would not be productive, but that the writing of an ID might force more serious consideration. We furthermore suggest that this ID be advanced as a BCP under the process for process change. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote: I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Splitting the question this way paves the way for those pushing for alternative formats to frame the next question as, Which alternative format are we going to allow?, as if it's already decided that we're going to allow *some* alternative and just have to find the best, or at least the least objectionable, even if there aren't any that fulfill the IETF's overall needs as well as plain ASCII text. If you add the qualifier, if they meet our requirements (... better than plain ASCII text?), then I doubt you'll get much disagreement with that statement, though you'll probably get a lot of discussion about how we don't yet *have* a specific list of requirements. As Brian's brown paper bag note suggests, we should start there, not with the assumption that we *will* allow some alternate format Personally, I'm skeptical that we'll find an alternative that meets our requirements as well, but perhaps we'll wind up with plain UTF-8 text or something. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: More on the Secretariat Statement of Work (SOW)
Firstly, I'll observe that this is outside the strict scope of the Secretariat SOW, since it covers the process cradle-to-grave, including WG, IESG, IANA and RFC Editor actions. Secondly, yes, dashboard metrics are a good idea, and are on the Tools team agenda, but often the devil is in the details and it's only by looking at specific cases of apparently stuck drafts that we can understand why things are moving slowly. Brian Spencer Dawkins wrote: Bernard/All, Ack on Bernard's note. I know that speed isn't the only thing that matters, but if we move slowly enough, the other stuff that matters won't matter. I'm remembering from previous discussions (sometime around the time of http://www3.ietf.org/proceedings/03mar/134.htm? or http://www3.ietf.org/proceedings/04mar/981.htm?) that the states we track in the ID tracker are sometimes overloaded, so it's hard to tell who has the token and exactly what is happening with the draft, and there are limits on what we've been able to do with metrics in the past. It's definitely worth thinking about this from a metrics perspective. Spencer In thinking through the Statement of Work (SoW), I think that an important component is to provide the IETF with sufficient information on how well the organization is performing. There are many metrics for that, but an important one is the time taken in various stages of the IETF process. Unfortunately, it is not clear to me that we are currently collecting this information in a form that makes it easy to analyze. We are also not analyzing the data on a regular basis, using it in a systematic effort to improve IETF performance (or at least to prevent it from deteriorating further). Researchers such as Tim Simcoe of the University of Toronto have studied metrics of IETF performance and have come to some interesting conclusions. For example, it appears that time from an initial -00 to RFC publication varies considerably by area, as well as by designation (Information, Experiemntal, Proposed). In the process of developing this research, Tim has also had to do significant work to adjust the data to make it suitable for analysis. My suggestion is that the IAOC needs to start thinking about what data and reports are needed to enable the IETF to measure and improve its performance. References -- Simcoe, T., Delays and de Jure Standards: What Caused the Slowdown in Internet Standards Development?, UC Berkeley Haas School of Business, April 2004. Simcoe, T., Standards Setting Committees, J.L Rotman School of Management, University of Toronto, Decmeber 2005. Available at: http://www.drizzle.com/~aboba/IAB/simcoe/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
--On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R \\(Jerry\\) [EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. If you do more of it, perhaps we can move some of the interoperability problems into the realm of actual IETF experience and out of the realm of extrapolation from other situations mixed with pure speculation. Free advice: if and when you want to move beyond that point, drop (or isolate into separate documents): (1) Recommendations for IETF process change or specific ways to determine consensus. They should be separate so they can be considered separately, using an appropriate process. (2) Distinguish clearly between what is required or tolerable for I-Ds and what is required or tolerable for RFCs. RFCs, in general, put a less strong requirement on easy extraction and modification of text than I-Ds. And, since I-Ds in theory expire after six months, you might be able to convince the community that the be sure it can be read twenty years later requirement for archival documents should not be taken as seriously for I-Ds. (3) Recommendations to permit any format that is (i) proprietary, or (ii) dependent on particular software for processing where that software carries either high costs, onerous licensing requirements, or licensing requirement that attempt to prohibit the development of independent tools to work with the format, or (iii) significantly operating-system dependent, or (iv) significantly version-dependent in the sense that the documents are not forward and backward compatible. I would suggest to you that the fact that Word hits a jackpot by satisfying all of the negative criteria in that third suggestion is the reason why it has been regularly rejected for IETF posting and working use in the past and is almost certain to be rejected in the future. If you want to consider that déjà vu (or deja vu, for ASCII-readers), it certainly is in the sense that we have been here before... but that rather misses the point: it has been rejected in the past for substantial and substantive reasons and the déjà vu situation, for me at least, is that someone decides to bring it up again every few years as if it had never been considered in the past. regards, john ___ Ietf mailing list
RE: Alternative formats for IDs
On Thursday, January 05, 2006 07:03:39 AM +0200 Yaakov Stein [EMAIL PROTECTED] wrote: [YJS] Actually, cuneiform on clay tablets and hieroglyphics on marble stelai seem to be better than paper if you really want your message to last a long time. I'm not convinced clay is better than paper; marble certainly is. However, neither is as widely deployed, probably due to the high costs of production and distribution. :-) -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Title: RE: objection to proposed change to "consensus" Yaakov, Here's the text that says "all that"... "It is much more likely to hear from the veryvocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change." The clear implication here is that we could choose to regard the 20 expressed 'nays', evenstrong nays, as atypical among the silent majority - if that assumption suits our purpose. Or, we could assume the reverse... The current process requires weighing of voices, not weighing of the supposed opinions of the silent. -- Eric From: Yaakov Stein [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 11:25 PMTo: Gray, Eric; Brian E CarpenterCc: ietf@ietf.orgSubject: RE: objection to proposed change to "consensus" However, the text objected to in this case argues thatthis process should be extended by a process of counting thepeople who don't publicly participate in the discussion, eitherway, as having tacitly given their approval to whatever side ofthe argument the authors, the WG chairs or the IESG choose.Wow, did we say all that? All we are saying is that for the issue we are discussing there is no WG. The only list that is open to its discussion is the general list, where there is no support. However, quite a large number of people who actively participate inIETF WGs (people who are interested in working on technical topics, but not on the internal workings of the IETF) who want the process changed. We proposed gauging interest by a show of hands at a plenary meeting, rather than by the number of yes votes on this list. Yes, even that is not optimal since there are people who prefer working in the terminal room or touring in the evenings, but it certainly seems to be a better way of finding out what MOST IETF participants want than only reading this list. I fail to see how this is equivalent to allowing authors or chairs to decide for themselves what should be done. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R \\(Jerry\\)" [EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say "never". Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is "good enough" has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please clarify this. Are you saying that if the WG/WGchairs/ADs agree that the non-ASCII version should be the normative version (because they want the better artwork), then that's OK? I thought I asked this a long time ago and was told no. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text including graphics will become the RFC? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On 01/05/2006 11:28 AM, John C Klensin allegedly wrote: Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. Yes. I support ASCII as the output format. I appreciate the discipline it encourages of separating protocol specification from descriptive text and figures, and of being very clear about state machines, etc. However, there are cases where descriptive text and figures are much more informative in some other format, so I wouldn't say never (nor should I be forced into a position of choosing between never and always). I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. 3 means draw toward the upper right. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Scott W Brim wrote: For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) Of course. By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. 3 means draw toward the upper right. This seems intuituve and easy, if your normal input device is a telephone keypad. Otherwise, why choose this example? -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
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 PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
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 Gray, Eric wrote: 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 PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. Agreed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Jerry, And this is a déjà vu over and over again as well. We could - in theory - allow draft versions in any format an author chooses. It would make quite a mess of the draft repository and - eventually - the RFC library. But we need to agree on one or more versions that can be (more or less) viewed by anyone, if we expect that everyone will actually read and use them. I believe the current practice allows for multiple formats, but requires that at least one is in ASCII text. And, in cases where the document is expected to be of an authoritative nature, the authoritative version is the one in the common (ASCII text) format. If that were acceptable to everyone, we could stop there, rather than taking the next baby step off the top stair. :-) However, there are a number of people who feel that complex figures are required to understand authoritative text in at least some cases - and this is a good argument for making a version that contains these complex figures authoritative. At this point, all agreement breaks down. The only way to go forward (assuming that change is part of the definition of going forward) is through arbitration. I am certain that (déjà vu, yet again) arbitration has been tried again and again... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ash, Gerald R (Jerry) -- Sent: Thursday, January 05, 2006 9:26 AM -- To: Yaakov Stein; ietf@ietf.org -- Cc: Ash, Gerald R (Jerry) -- Subject: Baby Steps (was RE: Alternative formats for IDs) -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the -- list discussion. I'm not very surprised with the way it -- has gone. Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the -- current discussion, I see few people arguing that ASCII -- text is all we need and that no other formats should ever -- be allowed. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Thanks, -- Regards, -- Jerry -- -- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Yaakov Stein -- Sent: Sunday, January 01, 2006 12:37 AM -- To: ietf@ietf.org -- Subject: Alternative formats for IDs -- -- Happy new year to everyone. -- -- I would like to call your attention to a new ID -- http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. -- -- This ID is the result of discussions here on the general list, -- and proposes the use of formats other than plain ASCII -- for IDs and RFCs. In particular, it proposes the allowance -- of diagrams other than ASCII-art as normative. -- -- The authors felt that further discussion on the list would -- not be productive, -- but that the writing of an ID might force more serious -- consideration. -- We furthermore suggest that this ID be advanced as a BCP -- under the process for process change. -- -- Y(J)S -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
John, I believe - for the record - that Post-Script is also allowed. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of John C Klensin -- Sent: Thursday, January 05, 2006 11:28 AM -- To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@ietf.org -- Subject: Re: Baby Steps (was RE: Alternative formats for IDs) -- -- -- -- --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R -- \\(Jerry\\) [EMAIL PROTECTED] wrote: -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the list -- discussion. I'm not very surprised with the way it has gone. -- Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the current -- discussion, I see few people arguing that ASCII text is all we -- need and that no other formats should ever be allowed. -- -- Even those of us who are strongly supportive of ASCII as our -- primary base format and those who believe that the effort needed -- to simplify illustrations and diagrams sufficiently that they -- can be accurately represented in ASCII artwork is helpful in -- forcing clarity are reluctant to say never. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Jerry, one of the nice things about baby steps is that you -- sometimes discover that the baby learned to take the steps -- without any instruction. -- -- Unless the IESG has changed the rules while I was not looking, -- it has been permitted to post I-Ds in PDF in addition to ASCII -- for some years. I find it interesting that it has not been taken -- advantage of more often (and, for the record, I'm one of those -- who has taken advantage of it). When it has been done for -- artwork purposes, the artwork in the ASCII version has sometimes -- been pretty rudimentary. In practice, whether it is good -- enough has been made on a case by case basis by WG Chairs and -- WGs or, for non-WG documents, by whether or not the relevant -- people are willing to read and consider those documents. -- Similarly, when PDF has been posted in order to exhibit -- non-ASCII characters, it has proven helpful to have Unicode -- character offsets (i.e., U+ representations) in both the -- ASCII and PDF forms to ensure complete precision even though the -- character-glyphs themselves appear only in the PDF form. -- -- So, consider the first baby step to have been taken: nothing -- prevents you from posting an I-D in both ASCII and PDF today, -- and the relevant sub-community will sort out, on a case by case -- basis, whether the ASCII is good enough. If you do more of it, -- perhaps we can move some of the interoperability problems into -- the realm of actual IETF experience and out of the realm of -- extrapolation from other situations mixed with pure speculation. -- -- Free advice: if and when you want to move beyond that point, -- drop (or isolate into separate documents): -- -- (1) Recommendations for IETF process change or specific -- ways to determine consensus. They should be separate so -- they can be considered separately, using an appropriate -- process. -- -- (2) Distinguish clearly between what is required or -- tolerable for I-Ds and what is required or tolerable for -- RFCs. RFCs, in general, put a less strong requirement -- on easy extraction and modification of text than I-Ds. -- And, since I-Ds in theory expire after six months, you -- might be able to convince the community that the be -- sure it can be read twenty years later requirement for -- archival documents should not be taken as seriously for -- I-Ds. -- -- (3) Recommendations to permit any format that is (i) -- proprietary, or (ii) dependent on particular software -- for processing where that software carries either high -- costs, onerous licensing requirements, or licensing -- requirement that attempt to prohibit the development of -- independent tools to work with the format, or (iii) -- significantly operating-system dependent, or (iv) -- significantly version-dependent in the sense that the -- documents are not forward and backward compatible. -- -- I would suggest to you that the fact that Word hits a jackpot by -- satisfying all of the negative criteria in that third suggestion -- is the reason why it has been regularly rejected for IETF
Re: objection to proposed change to consensus
Gray, Eric wrote: It is much more likely to hear from the very vocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change. While I can't speak for everyone else, this seems correct to me. Do I have anything useful or enteresting to add? and Do I think that my input will change the output? must both evaluate to Yes before I post to any discussion. I occasionally post for humor or interest, but generally I follow the discussion and stay out of it unless I believe it to be going badly awry. To be blunt, do we want every question to be answered by several thousand AOL Me too's? The silent masses are silent because they don't have anything useful to add, and believe that an endless stream of agreements would do nothing useful except test our bandwidth. We do, on the other hand, chime in when necessary. So, it is good and right and fair to assume that a public question with a default answer has concensus, if the only response is a minor negative one. I, and I believe many others, will simply move on to the next post when we see the question, if we agree with the default answer. A simple mental experiment: If we have, say, 2000 readers, and we post the question Will the sun rise tomorrow? We think yes. then we can expect a small number of disagreements, a small number of arguments from readers who didn't understand the question, a small number of AOL's, a small number of Of course, you twit! Why are you wasting our time with this? and nothing else. The vast majority of the readers will not reply, because they agree with the default answer, and they have other things to do. If there is a reader who disagrees in his mind, but is constrained by cultural conditioning or natural manners from speaking out, how are we supposed to coax his better way from this reader? We have already posited that he/she/it won't speak up. I submit that the IETF culture should, by policy, assume that anyone subscribed to an IETF list will speak out on any question if he/she/it thinks it right. The current process requires weighing of voices, not weighing of the supposed opinions of the silent. Yes, _but_ anyone who agrees will not argue. You will only get argument from those who disagree with the post. Unless you want to change the culture here to require an answer from every reader, on every question, thus adding significantly to our daily workload. I'd rather not. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
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 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 Gray, Eric wrote: 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 PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Please note that my e-mail address has changed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. Frankly, if the process of getting an ID published as an RFC seems to require (or at least encourage) use of at least one additional format, then the additional format(s) should also be incorporated in the RFC library. In other words, if there was a non-ASCII version of the ID, there should also be a non-ASCII version of the RFC. For some reason I thought this at least used to be the case. If it is not, then that should be fixed - for exactly the reasons you point out. Irrespective of questions about the legitimacy of using a non-ASCII version as normative or authoritative, the fact that a non-ASCII version might contain useful explanatory material is more than sufficient cause to keep it. -- Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stewart Bryant Sent: Thursday, January 05, 2006 12:01 PM To: John C Klensin Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org Subject: Re: Baby Steps (was RE: Alternative formats for IDs) John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R \\(Jerry\\) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Gray, Eric wrote: 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. That is not true, we don't address the need to include diagrams. - Stewart. This is - IMO - the basis for the apparent stodgy resistance to change. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Eliot Lear wrote: 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. The fact that we keep coming back to this topic may be a message in itself! - Stewart Eliot Gray, Eric wrote: 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 PROTECTED] [mailto:[EMAIL PROTECTED]] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On Thu, 5 Jan 2006, Scott Kitterman wrote: As I understand it, one of the major concerns of the people pushing for alternative formats is a desire to be able to include drawings and diagrams with something other than ASCII art. I don't believe that XML does much to help that. It does in the same way HTML does i.e. you can create separate drawing as jpg or png and include it in the document along with information as to how it would fit in that document. That means that if we use XML as publication or submission format, then data submitted for one draft/rfc can be more then just document itself (probably some rfc editor tools would need to be modified to take care of managing this too). In general it is a good idea to keep just document (i.e. it includes embedded pictures) for at least publication as official standard so I believe most appropriate is indeed to support PDF/A as official publication format but keep the source (XML pictures) available for those who need it as well. If one is worried about things like including pictures, diagrams, revision marks, etc. then I think looking into something like Open Document Format would make a lot more sense than considering a proprietary format like MS Word. You probably missed it, but I did in fact say in my earlier post that if we do want to consider direct editor format,then only good choice would be opendoc. The problem is that it is still relatively new and not enough programs and tools are available that support it on all platforms (but it is already supported in more systems then MS Word can!). That will surely change in the next few years if the format proves itself. Ultimately what I believe will happen is that there would be free (and commercial) tools to convert from MSWord XML (if that format stabilizes) to OpenDoc and back without any loss (at least as far as document text and its presentation) and so this means that those who want to use Word will be able to do it easily. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Stewart Bryant wrote: Eliot Lear wrote: 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. The fact that we keep coming back to this topic may be a message in itself! 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 11:49, Stewart Bryant wrote: Ken Raeburn wrote: Personally, I'm skeptical that we'll find an alternative that meets our requirements as well, but perhaps we'll wind up with plain UTF-8 text or something. How would I encode graphics in UTF-8? Same as you do in ASCII now (i.e., poorly), but you get a few more characters to choose from. :-) Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
--On Thursday, 05 January, 2006 13:17 -0500 Gray, Eric [EMAIL PROTECTED] wrote: Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. ... The number is not huge, but some RFCs have, in fact, been published formally in PS and/or PDF as well as in ASCII (and I'm on the hook for another one... something else in a too-long queue). See RFC 3550 and 3551 for recent standards-track examples and RFC 1119 for an a Full Standard example that is legendary in some parts of the community for incomprehensibility if one has only the ASCII text and diagrams. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Permitting PDF and Postscript (was: RE: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 05 January, 2006 12:46 -0500 Gray, Eric [EMAIL PROTECTED] wrote: John, I believe - for the record - that Post-Script is also allowed. It is indeed. And it, as well as PDF, are allowed in RFCs (see earlier note). As others have noted, an ASCII form is still required. I consider that a feature and, for various worst cases, futureproofing, but some others do not. And, as yet others have noted, it would be wise for us to get very specific about versioning and permitted feature-sets for PDF. It is arguably even more important to get specific about versions and feature sets for PS although my own personal opinion is that, given PDF, Postscript has about outlived its usefulness as a separate posting format. YMMD, of course, and this thread on the IETF list is probably not the optimal way to address that question in any event. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Thus spake Sandy Wills [EMAIL PROTECTED] Gray, Eric wrote: It is much more likely to hear from the very vocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change. While I can't speak for everyone else, this seems correct to me. Do I have anything useful or enteresting to add? and Do I think that my input will change the output? must both evaluate to Yes before I post to any discussion. I occasionally post for humor or interest, but generally I follow the discussion and stay out of it unless I believe it to be going badly awry. I think this thread long ago passed into badly awry, hence the volume of responses. The current process requires weighing of voices, not weighing of the supposed opinions of the silent. Yes, _but_ anyone who agrees will not argue. You will only get argument from those who disagree with the post. Unless you want to change the culture here to require an answer from every reader, on every question, thus adding significantly to our daily workload. I'd rather not. Very true for the original post, but once one person (or, in the instant case, a couple dozen) has argued with the OP, there is no way to determine which side the silent majority agrees with. It is possible that there are thousands of people agree with Yakov but have cultural prohibitions on backing him, or it could be that there are thousands that don't agree but have no new points to add -- or both. All we can measure are the people who do speak up. Right now it looks like there is a very strong consensus against MS Word as an output format, a weaker one against it as an input format, and no real consensus yet about other options like HTML, OpenDoc, PDF/A, etc. IMHO, the normative output text should remain the ASCII version, perhaps with UTF-8 to allow authors to add a native rendering of their name. Any other output versions should be optional and explicitly non-normative. Input forms should remain the same as today plus optional UTF-8. I think that's about as progressive as we'll likely build consensus for any time soon. The bad artwork that this saddles us with is, IMHO, a feature and not a bug. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Sandy, What you say is correct, as far as it goes. However, the implication in the wording is that people disagreeing with a proposal will post and people disagreeing with them will not. This is the case - as you suggest - when there is a clear default outcome. In fact, contrary to what we observe in nature, change is not the default outcome in most human organizations. That is because - as a careful analysis of this discussion over the years will disclose - there are as many ways to go with a change as there are people prepared to make changes. Consequently, it is at least as valid to assume that - particularly when a proposal represents a departure from status quo - that people may not be responding because they agree with the _objections_ already made and _also_ do not want to add to the general hub-bub. Consequently, if we see 10-20 people posting in favor of a _specific_ proposal and similar numbers posting against that same _specific_ proposal, then it is out of line for us to assume that any particular opinion is indicated by silence. Note that it is _very_ important to distinguish support for a particular change from support for the idea that some change is required. For example, if you have well over 100 people who all agree that change is required, and only 20 who argue that no change is required, you have to evaluate the agreement for a specific change (or at least a specific change direction) rather than a general discontent with status quo. If no more than 5 or 10 people agree to a specific proposal, then the net effect is a consensus for the status quo (better the devil you know). As one of the people arguing for status quo, I can tell you that it is not that I am happy with it. It is because I do not see a reasonably well supported alternative to status quo being proposed. In fact, a big part of the discussion right now stems from the fact that a lot of people have not really understood exactly what the status quo is. People who believe that they cannot submit an ID containing complex graphics in some form other than text, clearly do not realize that this is not the case. I like the quote about coffee, by the way... -- Eric -- -Original Message- -- From: Sandy Wills [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 12:48 PM -- To: Gray, Eric -- Cc: 'Yaakov Stein'; ietf@ietf.org -- Subject: Re: objection to proposed change to consensus -- -- Gray, Eric wrote: -- -- It is much more likely to hear from the very vocal -- people who are -- opposed to the change. That is, assuming 1000s of participants -- on the IETF discussion list, perhaps 20 expressed 'nays', even -- strong nays, could be considered a clear consensus in favor of -- change. -- -- While I can't speak for everyone else, this seems correct -- to me. Do I -- have anything useful or enteresting to add? and Do I -- think that my -- input will change the output? must both evaluate to Yes -- before I post -- to any discussion. I occasionally post for humor or interest, but -- generally I follow the discussion and stay out of it unless -- I believe it -- to be going badly awry. -- --To be blunt, do we want every question to be answered by several -- thousand AOL Me too's? The silent masses are silent because they -- don't have anything useful to add, and believe that an -- endless stream of -- agreements would do nothing useful except test our bandwidth. -- --We do, on the other hand, chime in when necessary. So, -- it is good -- and right and fair to assume that a public question -- with a default -- answer has concensus, if the only response is a minor -- negative one. I, -- and I believe many others, will simply move on to the next -- post when we -- see the question, if we agree with the default answer. -- --A simple mental experiment: If we have, say, 2000 -- readers, and we -- post the question -- --Will the sun rise tomorrow? We think yes. -- -- then we can expect a small number of disagreements, a -- small number of -- arguments from readers who didn't understand the question, a small -- number of AOL's, a small number of Of course, you twit! -- Why are you -- wasting our time with this? and nothing else. The vast -- majority of the -- readers will not reply, because they agree with the default -- answer, and -- they have other things to do. --If there is a reader who disagrees in his mind, but is -- constrained by -- cultural conditioning or natural manners from speaking out, -- how are we -- supposed to coax his better way from this reader? We -- have already -- posited that he/she/it won't speak up. --I submit that the IETF culture should, by policy, assume -- that anyone -- subscribed to an IETF list will speak out on any question -- if he/she/it -- thinks it right. -- -- The current process requires weighing of
PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 05 January, 2006 17:01 + Stewart Bryant [EMAIL PROTECTED] wrote: ... I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please clarify this. Are you saying that if the WG/WGchairs/ADs agree that the non-ASCII version should be the normative version (because they want the better artwork), then that's OK? I thought I asked this a long time ago and was told no. No, I'm not saying that. But the distinction I was trying to make is pretty subtle. The ASCII is the ASCII. Normative doesn't mean much for an I-D (see below for RFCs). The rule about PDF or Postscript versions is that they are supposed to be equivalent to the ASCII (and vice versa). But equivalent gets a little subjective... We know perfectly well that there are a few cases in which, no matter what one does with ASCII art, it is not sufficient to make whatever point is being made and supplemental text --more description, in words, of what would be in the pictures-- will not help much either. Now, part of the point that the people who have said if you can't do it in ASCII art, you generally shouldn't be doing it -- use the ASCII art and write a better description are making is that the cases in which we really need fancy pictures are very few and that, except for those cases, we are better off without them or at least being able to treat them as strictly supplementary. Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. Now, of course, some of them might argue that our current rules prevent them from contributing and that, if only we would let them submit documents written with the DeathRay word processor in Klingon script, not only would their productivity rise, but everyone else's would too --once we bought copies of DeathRay, learned Klingon, and persuaded UTC to get the characters into Unicode. However, that aside, assume that you are describing the new Mona Lisa protocol, and that it is really impossible to adequately describe the protocol without a high-resolution scale picture of the Mona Lisa overlaid with your coordinate system. The ASCII form of your document could (and must under our current rules) describe the coordinate system, include all of the measurements, and describe what you are doing with them. That text is normative (and the important thing is the text, not whether it is in ASCII or not) and has to be. But it is going to be _very_ hard for anyone to understand your protocol without seeing the picture unless they have a good mental image of it. Under those conditions, our precedents are that you can probably convince the WG/WGchairs/ADs, and eventually the RFC Editor, that a PDF document containing a picture of the Mona Lisa and an ASCII document with _- / \ _ | o o | | | | | __ | _ | | \_/ _ | | | | as a substitute for that picture, with the marginal lines roughly identifying your grid marks and coordinate system, is equivalent or as close to it as one can get. I would expect that to be a hard sell. I, personally, would _want_ it to be a hard sell. If it is really necessary, folks will figure out how to get the picture (maybe only the picture, which will probably not change from one version of the I-D to the next) to those who can't handle the PDF (or Postscript). But we have done it before, all of the needed rules and procedures are in place, and nothing new is needed other than your understanding that you are going to have to get consensus that the artwork is vital before making that great a departure between the ASCII and the PDF versions. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Stewart, Of course it is. I think virtually everyone would like to live in a perfect world and most of us recognize that this is not it. Therefore, it is clear that - whatever we might say in any particular argument - we all want things to get better. Consequently, proposals to change what is will always be a recurring event. The question we really have to ask - as dissected by Brian in some detail - is whether or not a specific proposal is enough better than what we have already (assuming that what we have already is both under- stood and used appropriately) to overcome the steady-state friction typically used to prevent change for the sake of marginal gain with an unquantifiable risk for unanticipated side effects. -- Eric From: Stewart Bryant [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 1:22 PM To: Eliot Lear Cc: Gray, Eric; Harald Tveit Alvestrand; ietf@ietf.org Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves] Eliot Lear wrote: 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. The fact that we keep coming back to this topic may be a message in itself! - Stewart Eliot Gray, Eric wrote: 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 PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- 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 PROTECTED] mailto:[EMAIL PROTECTED] 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 --
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Stewart, I didn't want to go through all the RFCs to find a specific example, but I distinctly recall seeing an RFC at one point that had figures which contained only the text see associated PS version. However, I know I can't expect anyone to take my word for it. However, there was an easy way to get around that. I simply ftp'd all 48 of the RFCs that are available in PS format. I am still somewhat at a loss to understand why there are none in PDF, but the observation that other formats may be used obviously still stands. The very first RFC available in PS was RFC 1119. Surprisingly enough, the entire contents of the ASCII version is as follows: 'RFC-1119 Network Time Protocol (Version 2) Specification and Implementation is available only in PostScript form in the file RFC1119.PS' So, what exactly are we arguing about? :-) -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 1:19 PM -- To: Gray, Eric -- Cc: 'Brian E Carpenter'; Harald Tveit Alvestrand; ietf@ietf.org -- Subject: Re: Engineering our way out of a brown paper bag -- [Re: Consensus b ased on reading tea leaves] -- -- Gray, Eric wrote: -- -- 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. -- -- -- -- That is not true, we don't address the need to include diagrams. -- -- - Stewart. -- --This is - IMO - the basis for the apparent stodgy -- resistance to change. -- -- -- -- Eric -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Brian E Carpenter -- -- Sent: Thursday, January 05, 2006 7:36 AM -- -- To: Harald Tveit Alvestrand -- -- Cc: ietf@ietf.org -- -- 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 PROTECTED] 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 -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
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. 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.) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Gray, Eric wrote: Sandy, In fact, contrary to what we observe in nature, change is not the default outcome in most human organizations. That is because - as a careful analysis of this discussion over the years will disclose - there are as many ways to go with a change as there are people prepared to make changes. I think that there is also a very strong element of emotional attachment to any system or solution, from those people who had a hand in creating it (Certainly, I'm just as guilty of this as the next guy!). Any job is harder if you have to change your tools every time you get used to them. It's also true that some people will object to anything in front of them, simply because it was done by someone else. We also have the religious responses, both pro and con, where someone either approves (or disapproves) of it simply because of the source. We've all seen It's gotta be good, Jon Postel wrote it, as well as I'll cut my wrists before I use MS software It appears that, if we want to judge solution-quality by mob volume, we need to find some way to separate the emotional responses from the reasoned responses. Unfortunately, I don't have one handy. Note that it is _very_ important to distinguish support for a particular change from support for the idea that some change is required. For example, if you have well over 100 people who all agree that change is required, and only 20 who argue that no change is required, you have to evaluate the agreement for a specific change (or at least a specific change direction) rather than a general discontent with status quo. If no more than 5 or 10 people agree to a specific proposal, then the net effect is a consensus for the status quo (better the devil you know). As one of the people arguing for status quo, I can tell you that it is not that I am happy with it. It is because I do not see a reasonably well supported alternative to status quo being proposed. ...And we are back to what has been said many times already. Do we want to change? Answer yes/no and What do we want to change to? are _not_ completely separable. You admit that you aren't happy about the status quo, but will still answer No to the first question because you don't trust us as a community to come up with a sane answer to the second question. The only quick and easy solution I see would be a multiple-choice question, perhaps on a web site, with options like: A) The world is perfect. Change nothing. B) I hate our system, but don't trust you bozos. Change nothing. C) Change to cunieform-and-clay, for everything. D) Change to marble for ID submission, and MS Word '95 for RFC publication. etc, etc, etc. I choose to _NOT_ volunteer to write and host this website. I like the quote about coffee, by the way... Thanks! While it's not original with me, I certainly still remember the pain involved with the source Unable to locate COMMAND.COM - Processor halted -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ABNF Re: Troubles with UTF-8
You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. I have yet to see any use of this in an I-D or RFC. I did post a question about this to this list on 24th December and the lack of response reinforces my view that this is uncharted territory. Tom Petch - Original Message - From: James Seng [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Wednesday, January 04, 2006 6:50 AM Subject: Re: Troubles with UTF-8 On 12/23/05, Tom.Petch [EMAIL PROTECTED] wrote: A) Character set. UTF-8 implicitly specifies the use of Unicode/IS10646 which contains 97,000 - and rising - characters. Some (proposed) standards limit themselves to ..007F, which is not at all international, others to -00FF, essentially Latin-1, which suits many Western languages but is not truly international. Is 97,000 really appropriate or should there be a defined subset? Why should there be a subset? You really really dont want to go into a debate of which script is more important then the other. B) Code point. Many standards are defined in ABNF [RFC4234] which allows code points to be specified as, eg, %b00010011 %d13 or %x0D none of which are terribly Unicode-like (U+000D). The result is standards that use one notation in the ABNF and a different one in the body of the document; should ABNF allow something closer to Unicode (as XML has done with #000D;)? Following RFC4234, Unicode code point U+ABCD will just be represented as %xABCD. I do not see the problem you mention or am I missing something? snip http://www.unicode.org/charts/ -James Seng ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Sandy, My point - as may be clearer in other posts - is that the first question do we want change is a no-op at best. Change is natural and inevitable whether we want it or not. The first useful question is - paraphrasing what Brian said - what do we need that we do not already have? All of us have needs that are not satisfied by what we have - hence the inevitability of change. But it is not useful, nor realistic, for any of us to assume that everyone else is going to drop what they're doing to help us satisfy our individual needs. So the question becomes Is there a common subset of our collective individual needs that a large subset of affected people agree on, that cannot be satisfied by what we have now? IMO, that is the question we keep coming back to... -- Eric -- -Original Message- -- From: Sandy Wills [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 3:34 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: objection to proposed change to consensus -- -- Gray, Eric wrote: -- -- Sandy, -- --In fact, contrary to what we observe in nature, change -- is not the default outcome in most human organizations. -- That is because - as a careful analysis of this discussion -- over the years will disclose - there are as many ways to go -- with a change as there are people prepared to make changes. -- -- I think that there is also a very strong element of emotional -- attachment to any system or solution, from those people who -- had a hand -- in creating it (Certainly, I'm just as guilty of this as -- the next guy!). -- Any job is harder if you have to change your tools every -- time you get -- used to them. -- It's also true that some people will object to anything -- in front of -- them, simply because it was done by someone else. -- We also have the religious responses, both pro and con, where -- someone either approves (or disapproves) of it simply -- because of the -- source. We've all seen It's gotta be good, Jon Postel -- wrote it, as -- well as I'll cut my wrists before I use MS software -- -- It appears that, if we want to judge solution-quality -- by mob volume, -- we need to find some way to separate the emotional -- responses from the -- reasoned responses. Unfortunately, I don't have one handy. -- --Note that it is _very_ important to distinguish support -- for a particular change from support for the idea that some -- change is required. For example, if you have well over 100 -- people who all agree that change is required, and only 20 who -- argue that no change is required, you have to evaluate the -- agreement for a specific change (or at least a specific change -- direction) rather than a general discontent with status quo. -- If no more than 5 or 10 people agree to a specific proposal, -- then the net effect is a consensus for the status quo (better -- the devil you know). -- --As one of the people arguing for status quo, I can tell -- you that it is not that I am happy with it. It is because I -- do not see a reasonably well supported alternative to status -- quo being proposed. -- -- ...And we are back to what has been said many times -- already. Do we -- want to change? Answer yes/no and What do we want to -- change to? are -- _not_ completely separable. You admit that you aren't -- happy about the -- status quo, but will still answer No to the first -- question because you -- don't trust us as a community to come up with a sane answer to the -- second question. -- -- The only quick and easy solution I see would be a -- multiple-choice -- question, perhaps on a web site, with options like: -- --A) The world is perfect. Change nothing. --B) I hate our system, but don't trust you bozos. Change nothing. --C) Change to cunieform-and-clay, for everything. --D) Change to marble for ID submission, and MS Word '95 for RFC -- publication. --etc, etc, etc. -- --I choose to _NOT_ volunteer to write and host this website. -- -- --I like the quote about coffee, by the way... -- -- Thanks! While it's not original with me, I certainly still -- remember the -- pain involved with the source Unable to locate COMMAND.COM -- - Processor -- halted -- -- -- -- Unable to locate coffee. -- Operator halted. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Permitting PDF and Postscript (was: RE: Baby Steps (was RE: Alternative formats for IDs))
In message [EMAIL PROTECTED], John C Klensin writes: --On Thursday, 05 January, 2006 12:46 -0500 Gray, Eric [EMAIL PROTECTED] wrote: John, I believe - for the record - that Post-Script is also allowed. It is indeed. And it, as well as PDF, are allowed in RFCs (see earlier note). As others have noted, an ASCII form is still required. I consider that a feature and, for various worst cases, futureproofing, but some others do not. And, as yet others have noted, it would be wise for us to get very specific about versioning and permitted feature-sets for PDF. It is arguably even more important to get specific about versions and feature sets for PS although my own personal opinion is that, given PDF, Postscript has about outlived its usefulness as a separate posting format. YMMD, of course, and this thread on the IETF list is probably not the optimal way to address that question in any event. Producing good, portable PDF isn't obvious. I just added the following text to a Call for Papers of a conference I'm chairing, based on many sad experiences trying to read random PDF files submitted by others: PDF users should use Type 1 fonts instead of Type 3, and should Embed and Subset all fonts. You can find instructions on how to do this at https://www.fastlane.nsf.gov/documents/pdf_create/pdfcreate_01.jsp and http://ismir2005.ismir.net/pdf.html Among the problems I've encountered have been version skew, missing fonts (especially Asian language fonts that are frequently not installed elsewhere), fuzzy text from LaTeX users who are generating bitmap fonts, ligatures getting changed into weird characters, and more. When I sent the PDF for the second edition of my book to the publisher, I had to use these options to dvips: -P pdf -G0 and -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 -dSubsetFonts=true -dEmbedAllFonts=true for ps2pdf. (I've left out the resolution.) I should note that it didn't work, either -- but if I sent them the PS, they could convert it to PDF. We never did figure out that problem --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ABNF Re: Troubles with UTF-8
See: 2.2. ABNF for IRI References and IRIs in: http://www.ietf.org/rfc/rfc3987.txt Misha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom.Petch Sent: 05 January 2006 20:15 To: James Seng Cc: ietf Subject: ABNF Re: Troubles with UTF-8 You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. I have yet to see any use of this in an I-D or RFC. I did post a question about this to this list on 24th December and the lack of response reinforces my view that this is uncharted territory. Tom Petch To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy Wills wrote: [..] A simple mental experiment: If we have, say, 2000 readers, and we post the question Will the sun rise tomorrow? We think yes. Then you invite ridicule upon anyone who says no. However, consider this case: you post Should we move to using MS Word? and 5 minutes later some hardy soul posts No. Over the next few minutes to hours some hundreds or thousands of list members' mail servers will receieve these two emails. Many of the human recipients will, in one quick glance, see two positions staked out - one for MS Word, one against. With which one does the silent majority agree? cheers, gja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
grenville armitage wrote: However, consider this case: you post Should we move to using MS Word? and 5 minutes later some hardy soul posts No. Over the next few minutes to hours some hundreds or thousands of list members' mail servers will receieve these two emails. Many of the human recipients will, in one quick glance, see two positions staked out - one for MS Word, one against. With which one does the silent majority agree? Indeterminate, of course. This is why, as so many people have pointed out time time again, if concensus is to be requested or claimed, propositions on this list a) MUST be kept simple, and b) MUST include a default. What you gave us is an example of a discussion, which can include more than one topic, including more than one possible answer. This should not be confused with, or used as justification for, a claim of concensus. Eventually, we will all be exhausted by this interminal discussion, and someone (I think Brian Carpenter is the poor guy stuck with this job) will post a simple statement and ask if the statement has concensus. No multiple choice, no discussion, just statement. I hope it happens soon... The IETF should publish RFCs in the traditional text format, plus WordStar version 2.0 of 4/1/1987. Henceforth, all posters suggesting MS Word will be drug from their homes and stoned in the street. People who agree will mumble yeah under their breath and otherwise ignore the post. People who disagree will reply on the list. After two weeks, someone will compare the size of the subscriber list to the number of negative replies, and we'll all start gathering rocks together. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy Wills wrote: grenville armitage wrote: However, consider this case: you post Should we move to using MS Word? and 5 minutes later some hardy soul posts No. Over the next few minutes to hours some hundreds or thousands of list members' mail servers will receieve these two emails. Many of the human recipients will, in one quick glance, see two positions staked out - one for MS Word, one against. With which one does the silent majority agree? Indeterminate, of course. This is why, as so many people have pointed out time time again, if concensus is to be requested or claimed, propositions on this list a) MUST be kept simple, and b) MUST include a default. My example was (a) simple, and (b) had a default. What you gave us is an example of a discussion, What I demonstrated is that any posed question on a mailing list will, if it solicits replies taking positions for or against, lead to an indeterminate state when interpreted through logic that states the silent majority agrees with the position stated on the mailing list. Every subsequent response to the 'first' question will itself stake out a position, and you have no right to assume the 'majority' care more about the 'first post' of the question than the followups. cheers, gja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
(comments inline, but the summary is that _I_ read your words and apparently get a different meaning from when _you_ read your words) grenville armitage wrote: Sandy Wills wrote: grenville armitage wrote: However, consider this case: you post Should we move to using MS Word? A simple yes/no question, with no default given by the poster. Those are your words, not mine. and 5 minutes later some hardy soul posts No. This is, in your example, the first choice available, since the original question had no default/assumed answer. Over the next few minutes to hours some hundreds or thousands of list members' mail servers will receieve these two emails. Many of the human recipients will, in one quick glance, see two positions staked out - one for MS Word, one against. Thus we have a discussion With which one does the silent majority agree? Indeterminate, of course. This is why, as so many people have pointed out time time again, if concensus is to be requested or claimed, propositions on this list a) MUST be kept simple, and b) MUST include a default. My example was (a) simple, and (b) had a default. Please read your words again. Your example was an open question, with no default, leading to a discussion. Maybe I'm not expressing myself clearly enough. Okay, maybe that's because we don't use the same definitions for the words and phrases we are passing back and forth. You keep describing our discussions, and I agree that, yep, that's the way our discussions work. I keep trying to point out that this is different from how we call for concensus, and you keep going back to but that's not how our discussions work. You're right, because a discussion is _different_ from a call for concensus (henceforth CfC), and we will never be able to REACH a concensus if you can't tell the difference. (and I think that this confusion is one of the IETF's big problems) For the sake of this discussion, here are a couple of working definitions. Please let me know if you see a problem with them: A Discussion has many speakers, many viewpoints, many issues, many proposed solutions, and, well, discussion about them all, lasting for (sometimes) a long time. A CfC usually follows a Discussion and has ONE (count 'em) statement, by ONE (count 'em) person, expressing a clear value or decision, asking for agreement or disagreement. It may or may not be bundled with justifying data or logic, as long as the readers can find the CfC. This CfC is followed by a variable number of replies agreeing or disagreeing with the statement. Once that is done, the group can take the results of that CfC and move forward, with either another discussion, or a further CfC, as seems useful. If your example had been a _statement_ We should move to MSWord, then that would have worked for a CfC. (I believe that such a CfC would collect a large number of Nos, with many of them giving reasons.) However, wording it as a question Should we... is asking for a discussion, not a CfC. And we cannot ever reach a concensus if we can't tell the two apart. For the record, I believe that the Chair should issue a CfC on We should allow non-ASCII graphics to accompany IDs and RFCs. If, and only if, that CfC passes, we should explore what format those graphics might be. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy Wills wrote: someone (I think Brian Carpenter is the poor guy stuck with this job) will post a simple statement and ask if the statement has concensus. No multiple choice, no discussion, just statement. I hope it happens soon... The IETF should publish RFCs in the traditional text format, plus WordStar version 2.0 of 4/1/1987. Henceforth, all posters suggesting MS Word will be drug from their homes and stoned in the street. [...] and we'll all start gathering rocks together. Without an opportunity to sell fake beards for this episode in the Life of Brian the proposal could meet some resistance ;-) Not new, see http://article.gmane.org/gmane.ietf.general/13554 or the clear http://article.gmane.org/gmane.ietf.general/13658 Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy Wills wrote: [..] A CfC usually follows a Discussion and has ONE (count 'em) statement, by ONE (count 'em) person, expressing a clear value or decision, asking for agreement or disagreement. ...asking for agreement or disagreement. If it quacks like a question... cheers, gja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Permitting PDF and Postscript
Steven M. Bellovin wrote: Producing good, portable PDF isn't obvious. My recent experience is that I got a paper in PDF, though plain text was more than enough for the paper, and it included an e-mail address to which I send a mail. I used Adobe original PDF reader (version 7.0) and, to make sure that I won't wrongly type or copy the address, used reader's function to automatically detect e-mail addresses in PDF files (PDF may contain hyperlinks and recent PDF reader of Adobe optionally detect additional hyperlinks in text automatically. Both types of links are not distinguishable). Later, I have noticed that the mail failed, because the PDF reader has a bug that the auto detection does not work for e-mail addresses containing -. IMHO, the person who choosed the PDF format should be responsible for the failure. I hope IETF won't make similar mistakes. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ISMS WG Interim Meeting
The IETF ISMS Working Group will hold an interim meeting on February 13-14, 2006. The meeting will be hosted by the Massachusetts Institute of Technology at 304 Vassar Street in Cambridge, MA USA. The primary purpose of this meeting will be solving open issues that concern Internet drafts draft-ietf-isms-secshell-00.txt and draft-ietf-isms-tmsm-00.txt. The WG started an intensive face-to-face discussion of these issues at the IETF meeting in Vancouver. But for making significant progress, far more meeting time is needed than one can get at a regular IETF meeting. For details on meeting agenda, venue, hotel, please see the meeting web page http://www.eecs.iu-bremen.de/wiki/index.php/01._ISMS_Interim. Anyone who plans to join the meeting, please send a message to the WG co-chairs so that sufficient meeting space can be reserved. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IESG Statement on AUTH48 state
The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IESG evaluation of RFC 3683 PR-Action for Dean Anderson
The IESG has evaluated the possibility of a RFC 3683 PR-action for Dean Anderson. Please see the following URL for the corresponding Last Call message and associated information: http://www.ietf.org/mail-archive/web/ietf/current/msg38293.html There was extensive discussion on the IETF list and the IESG received additional feedback directly. After a careful evaluation of the feedback, mail archives, IESG minutes and RFC 3683, the IESG has concluded that there is sufficient evidence that Mr. Anderson has repeatedly engaged in behavior that is not acceptable on IETF mail lists. RFC 3683 mentions the possibility of using successive posting bans to try to modify such behavior. However, it does not normatively require such bans. Mr. Anderson has repeatedly been warned that his postings were unacceptable but he failed to heed such warnings, and while often moderating his behavior for a limited amount of time, he has not modified his behavior permanently. To summarize, the IESG concluded that serious and repeated efforts to make Mr. Anderson change his behavior did not succeed and that Mr. Anderson's conduct was exactly the kind of conduct that RFC 3683 requires for a PR-action. Therefore, the IESG has decided to take an RFC 3683 PR-Action for Dean Anderson. The IESG has requested the secretariat to remove posting rights for Dean Anderson for the IETF discussion list. As RFC 3683 prescribes, maintainers of any IETF mailing list may, at their discretion, also remove posting rights to that IETF mailing list. The IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
