RE: Printing IDs and RFCs (Was: Re: ASCII art)
You mean something like http://draft-ietf-pwe3-satop.potaroo.net? No, all I want is to find the latest ID - the one on the IETF site. (If I go to watersprings they show me all archived versions, and I can easily find the latest one.) Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Printing IDs and RFCs (Was: Re: ASCII art)
-- but I will in a couple of minutes from this posting! Sorry, but in my previous email (in reply to your previous one) I misunderstood your intention. I have tried it out, and it works great. The draft-ietf-working-group is great, and I noticed that draft-stein works as well (although it brings up draft-steinback-xxx and draft-steinberger-xxx as well. perhaps respecting the hyphens makes more sense) Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
I-D file formats and internationalization
I've noticed that the recent debate on the ASCII text format has often conflated formatting of artwork and Unicode support. I think finding a non-text artwork format that has free uniform authoring (including diffs) and viewer support will be impossible for the next 5-10 years. An XML equivalent to Postscript may eventually be widely implemented. The current effort, SVG, is a massive specification, unevenly implemented, and lacks a thorough test suite. Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. So, I recommend that the IETF secretariat and the RFC Editor change their policies to allow UTF-8 text files. That way, older RFCs and I-Ds produced using the current tools would follow the same encoding. I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline - Fact or Fiction?
The reason we have the deadline is to protect the Secretariat from having to be heroes. However, best would be if the need for such protection didn't arise. Instead of assuming that things to be discussed in the meetings will be written just before the meeting, and creating complexity and bureaucracy around that assumption, institute a policy that nothing *will* be discussed in the meeting unless it has already been discussed on the mailing list and the WG has failed to reach agreement on the issue (note this is about issues, not documents). This will reduce the number of drafts which must get out just before the meeting to only those which capture the result of ongoing discussion. The others won't get discussed anyway. OK, I'm optimistic, but I see all this discussion of mechanisms to elaborate a situation we don't want to be in in the first place. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ASCII art
Yaakov Stein wrote: I created a random svg file with Inkscape, a cross-platform svg drawing app. I created an artwork element with src=pretty.svg; it displayed inline in the cross-platform xxe XML editor using my xml2rfc plugin (but no inline editing of the graphic) and converted to PDF reasonably well: I returned to the original subject line, as I wish to return to the idea behind the original thread. Figures are not just nice to have additions to text. There are good reasons to include diagrams that would be impossible to use today. For example, the ITU has come up with a diagrammatic technique for describing transport networks (see e.g. G.805 and G.809). Its use is now required in all new work there, and the technique is not just descriptive, it is genuinely useful for catching bugs and as the final word when English language descriptions differ. Such a technique could not be adopted at the IETF under the present ID system, as there would be no normative method of distributing the diagrams. I agree with Yaakov here. Graphics are a language that allows us to abstract and describe concepts in a way that is much clearer (to reader and writer) than is possible in words or crude diagrams. I strongly suggest that folks take a look at the clarity of the work that the ITU are now producing. They are a major competitor for mind share in many areas of importance to us (for example MPLS, Pseudowire, VoIP etc). - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Scott, Interesting thoughts. One thing I can see as being possibly a bit of a problem is that this approach - as opposed to the present one - would most likely impose a different sort of problem on a lot of people (the Secretariat, the host sponsor and the meeting Hotel - just to name a few). Making your - admittedly optimistic - assumption and following it to a conclusion leads me to suspect that many (possibly most) WG meetings would likely be subject to last-minute cancellation if all remaining issues are resolved immediately before the meetings. In many ways, this would be a good result. The possibility of being able to avoid the trip would add incentives to resolve issues before the meeting. People who can't make it to a meeting would miss less if even a few issues were resolved on the mailing list before the meetings. In other ways, however this would be not so good. Hotels that lost as many as 2,500 bookings on the Saturday or Sunday before the meeting would black-list the IETF making it very difficult to set up future meetings. The host sponsor(s) would not be able to guess how much equipment and resources would be required. The Secretariat will be in a walking nightmare simply trying to juggle room bookings to accommodate meeting cancellations and rescheduling. Attendees will most likely not know if and when meetings will be held. People will have made travel plans around meetings that may or may not happen. And so on. And don't for a minute think that Employers would fail to note that issues got resolved prior to a trip to Iceland but not before a similar meeting in Hawaii. I think things would eventually settle out. For example, the IETF currently has enough going on that statistical methods should find some applicability (how many will actually end up coming, how many rooms will be needed and for how long). But the transition would be _tough_. -- Eric -- -Original Message- -- From: Scott W Brim [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, November 30, 2005 8:33 AM -- To: Joel M. Halpern; Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- The reason we have the deadline is to protect the Secretariat from -- having to be heroes. However, best would be if the need for such -- protection didn't arise. -- -- Instead of assuming that things to be discussed in the meetings will -- be written just before the meeting, and creating complexity and -- bureaucracy around that assumption, institute a policy that nothing -- *will* be discussed in the meeting unless it has already been -- discussed on the mailing list and the WG has failed to -- reach agreement -- on the issue (note this is about issues, not documents). This will -- reduce the number of drafts which must get out just before -- the meeting -- to only those which capture the result of ongoing discussion. The -- others won't get discussed anyway. OK, I'm optimistic, but -- I see all -- this discussion of mechanisms to elaborate a situation we don't want -- to be in in the first place. -- -- swb -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline - Fact or Fiction?
On Wed, Nov 30, 2005 10:07:27AM -0500, Gray, Eric allegedly wrote: Making your - admittedly optimistic - assumption and following it to a conclusion leads me to suspect that many (possibly most) WG meetings would likely be subject to last-minute cancellation if all remaining issues are resolved immediately before the meetings. You're even more optimistic than I am. Essentially every WG has problems that are not resolved by e-mail (and are rarely resolved even in person). I wouldn't expect any change in who meets, just in the meeting logistics. Those that are free of these problems need never meet in person. And don't for a minute think that Employers would fail to note that issues got resolved prior to a trip to Iceland but not before a similar meeting in Hawaii. :-). There you go, another criterion for venue selection. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Scott, Hmmm. I thought your optimistic assumption was that people would try to resolve issues before the meetings. It may be that I misunderstood, or simply that I am not aware of much of what goes on in the background at meetings. At most meetings, the usual procedure is for people to talk about the information most listeners would know already if they read the draft and paid attention to the mailing list. Then the usual questions are: 1) do we accept the draft as a WG document or 2) is the draft ready for last call? After the WG (co-)chair(s) tally hands, or hum-levels, the question then goes to the mailing list. This is the procedure for about 5 out of 6 presentations, almost all the time. These questions rarely (if ever) get asked before the meeting and - in many cases - the information people have after the meeting is not any different than they had before the meeting. Since the majority of not particularly contentious stuff gets resolved this way, I would suspect that merely asking the question before the meeting - rather than after the meeting - might eliminate much of the work that currently takes up time during each WG meeting. Of course this is based on optimistic assumptions like people read the drafts before the meeting and people would aggressively try to resolve at least the easily resolved issues. At a minimum, this would result in a lot of half-hour or one hour meetings instead of one and two hour meetings. But in other cases (where - for example - the only thing discussed during the meeting is document status) - there would be little point in having the meeting if the inforamtion was simply put out on the mailing list before the meeting and there were no questions about it. I believe that making less optimistic assumptions would mean no change in any respect. I tend to believe this, more pessimistic, view is more likely. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of 'Scott W Brim' -- Sent: Wednesday, November 30, 2005 10:36 AM -- To: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- On Wed, Nov 30, 2005 10:07:27AM -0500, Gray, Eric allegedly wrote: --Making your - admittedly optimistic - assumption and following -- it to a conclusion leads me to suspect that many -- (possibly most) WG -- meetings would likely be subject to last-minute -- cancellation if all -- remaining issues are resolved immediately before the meetings. -- -- You're even more optimistic than I am. Essentially every WG has -- problems that are not resolved by e-mail (and are rarely -- resolved even -- in person). I wouldn't expect any change in who meets, just in the -- meeting logistics. Those that are free of these problems need never -- meet in person. -- --And don't for a minute think that Employers would fail to note -- that issues got resolved prior to a trip to Iceland but -- not before a -- similar meeting in Hawaii. -- -- :-). There you go, another criterion for venue selection. Out of curiosity, are you suggesting that meetings should be scheduled in inhospitable climates so that the incentive for resolving issues is higher, or are you suggesting the obverse? -- -- swb -- -- ___ -- 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: I-D file formats and internationalization
Robert, This is a good point. It even applies to the IETF secretariat. It used to be impossible to register with your real name if it contained non-ASCII characters. I think that has changed, I recall having Seen Olafur Gudmundson's badge with the real Icelandic curly d (or whatever it is called in English) at a recent meeting. I have not seen Japanese or Chinese or Korean, which I guess would be the next logical step... Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Tue, 29 Nov 2005, Robert Sayre wrote: I've noticed that the recent debate on the ASCII text format has often conflated formatting of artwork and Unicode support. I think finding a non-text artwork format that has free uniform authoring (including diffs) and viewer support will be impossible for the next 5-10 years. An XML equivalent to Postscript may eventually be widely implemented. The current effort, SVG, is a massive specification, unevenly implemented, and lacks a thorough test suite. Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. So, I recommend that the IETF secretariat and the RFC Editor change their policies to allow UTF-8 text files. That way, older RFCs and I-Ds produced using the current tools would follow the same encoding. I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. Robert Sayre ___ 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: I-D file formats and internationalization
It was sad that people can accept this. To degrade the name of their friends. In every country this is insulting. It is good news you can type better. But this has not changed in RFC. If in the thanks section you hurt a name. The thanked person, will not be happy. Eduardo Mendez 2005/11/30, Ole Jacobsen [EMAIL PROTECTED]: Robert, This is a good point. It even applies to the IETF secretariat. It used to be impossible to register with your real name if it contained non-ASCII characters. I think that has changed, I recall having Seen Olafur Gudmundson's badge with the real Icelandic curly d (or whatever it is called in English) at a recent meeting. I have not seen Japanese or Chinese or Korean, which I guess would be the next logical step... Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Tue, 29 Nov 2005, Robert Sayre wrote: I've noticed that the recent debate on the ASCII text format has often conflated formatting of artwork and Unicode support. I think finding a non-text artwork format that has free uniform authoring (including diffs) and viewer support will be impossible for the next 5-10 years. An XML equivalent to Postscript may eventually be widely implemented. The current effort, SVG, is a massive specification, unevenly implemented, and lacks a thorough test suite. Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. So, I recommend that the IETF secretariat and the RFC Editor change their policies to allow UTF-8 text files. That way, older RFCs and I-Ds produced using the current tools would follow the same encoding. I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. Robert Sayre ___ 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: I-D file formats and internationalization
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. So, I recommend that the IETF secretariat and the RFC Editor change their policies to allow UTF-8 text files. That way, older RFCs and I-Ds produced using the current tools would follow the same encoding. I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. It might seem odd to people whose names do fit in ASCII but there are a lot of people who care about this type of issue. In effect the message is sent out 'you do not really belong here', 'you are a second class citizen', 'the IETF is an American organization and the only people who really matter are going to be American'. The fact that Brian is English and lives in Zurich is irrelevant. People take their names very seriously and personally. It's a question of outreach. Having one meeting out of three held outside North America each year is not outreach, it is a holiday. I am currently at the W3C AC meeting. They are also involved in the ongoing 'internet governance' discussions but the W3C is involved a participant in the discussions while the IETF is one of the topics of the discussions. Needless to say it is better to be a participant than the topic. The W3C has avoided concern by being conspicuously international in its approach. The IETF has had the attitude 'this is the way we do things here, nobody asked you to like it'. So far 700 translations of W3C specifications have been made by volunteers. I don't know what the quality of the translations are, I would certainly be upset if one of my engineers used a translation as the basis for writing running code. But those translations are certainly used by academics to teach comp-sci courses in those languages and a large number of students who would have found it difficult to understand the material in translation have come to understand and use the specification. It is simply a fact of modern life that the ability to speak English well is an essential qualification for almost all forms of knowledge work, particularly at the research and elite levels. That does not mean that a group of mostly English speakers should also make good English an essential qualification at the apprentice and journeyman stages of learning the craft. Phill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
Ole Jacobsen writes... This is a good point. It even applies to the IETF secretariat. It used to be impossible to register with your real name if it contained non-ASCII characters. I think that has changed, I recall having Seen Olafur Gudmundson's badge with the real Icelandic curly d (or whatever it is called in English) at a recent meeting. I have not seen Japanese or Chinese or Korean, which I guess would be the next logical step... While this is a bit of a digression, the purpose of IETF badges is (at least) two-fold. First, to show that the bearer has paid the registration fee, and second, to allow other attendees to address the bearer by name during sessions and informal conversations. If badges were in non-Latin character sets, it would make it difficult for me to address the bearer in English. It seems that there are parallels for RFCs and I-Ds. If the official language of these documents is English, then should we have portions of those documents represented in other languages, and more at issue, other character sets? In the attributions sections, one could, of course, provide a Latin character set representation in addition to the native national character set, for names, addresses, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
Phillip: I am currently at the W3C AC meeting. They are also involved in the ongoing 'internet governance' discussions but the W3C is involved a participant in the discussions while the IETF is one of the topics of the discussions. Needless to say it is better to be a participant than the topic. The only thing worse than being talked about is NOT being talked about. -- Oscar Wilde So far 700 translations of W3C specifications have been made by volunteers. Yes, VOLUNTEERS! Nobody is stopping anyone from translating the RFCs. I'd have to bet it's been done in quite a few cases. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Why are we so exceptional [was: Translations of standards (was: RE: ASCII art)]
Wouldn't having quasi-authoritative translations *result* in balkanization? The Chinese National Standard series comes immediately to mind of authoritative translations *with interpretations*. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JFC (Jefsey) Morfin Sent: Monday, November 21, 2005 8:08 PM To: ietf@ietf.org Subject: Why are we so exceptional [was: Translations of standards (was: RE: ASCII art)] At 20:49 21/11/2005, John C Klensin wrote: --On Monday, 21 November, 2005 11:16 -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I think that a better case to make wrt internationalization is that it is hard to see how a pure ASCII document is ever going to provide a satisfactory description of a protocol that is based on unicode. This is an entirely different issue from the one that I think Jefsey was raising and Tom was responding to. Conflating them gets us nowhere at all. I commented Paul Hoffman's response to Julien Maisoneuve about why we are so exceptional. Nothing else. May be should I have changed the subject. This is now done. And that takes us back to Paul's original comment, at least as I understood it -- the important thing is the quality of the writing. Access to fancy formatting and presentation tools may make good writing easier to follow and, in particular, to let the reader get the gist of what is going on before trying to deeply study the text. But adding fancy formatting and presentation to poor writing will, at best, only hide, for a while, the fact that the explanations are inadequate. Agreed. But I hope you do not imply non-ASCII English is fancy formatting and goes with inadequate explanations. And, by not forcing the extra discipline that writing without a dependence on clever illustrations requires, it may make it more likely that we will get documents whose inadequacies are harder to detect. ASCII Draft is not the main point here. But it is true that a good draft often speaks more than long texts. As I said, that conclusion could change as experience with protocols based on Unicode expands. But, so far, we have almost no experience along that dimension (and, incidentally, neither do ISO or ITU or IEEE, at least as far as I know). I have no idea of what are protocols based on Unicode. I only know that equal linguistic opportunity and common global interest mean that authoritative protocols and procedures should be producible in every language and aggregated into the IETF document body. Not fully permitting this would only increase the risks of balkanization of the Internet. jfc ___ 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: I-D file formats and internationalization
For that matter, most Americans don't speak English Mark On Nov 30, 2005, at 10:43 AM, Hallam-Baker, Phillip wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. So, I recommend that the IETF secretariat and the RFC Editor change their policies to allow UTF-8 text files. That way, older RFCs and I-Ds produced using the current tools would follow the same encoding. I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. It might seem odd to people whose names do fit in ASCII but there are a lot of people who care about this type of issue. In effect the message is sent out 'you do not really belong here', 'you are a second class citizen', 'the IETF is an American organization and the only people who really matter are going to be American'. The fact that Brian is English and lives in Zurich is irrelevant. People take their names very seriously and personally. It's a question of outreach. Having one meeting out of three held outside North America each year is not outreach, it is a holiday. I am currently at the W3C AC meeting. They are also involved in the ongoing 'internet governance' discussions but the W3C is involved a participant in the discussions while the IETF is one of the topics of the discussions. Needless to say it is better to be a participant than the topic. The W3C has avoided concern by being conspicuously international in its approach. The IETF has had the attitude 'this is the way we do things here, nobody asked you to like it'. So far 700 translations of W3C specifications have been made by volunteers. I don't know what the quality of the translations are, I would certainly be upset if one of my engineers used a translation as the basis for writing running code. But those translations are certainly used by academics to teach comp-sci courses in those languages and a large number of students who would have found it difficult to understand the material in translation have come to understand and use the specification. It is simply a fact of modern life that the ability to speak English well is an essential qualification for almost all forms of knowledge work, particularly at the research and elite levels. That does not mean that a group of mostly English speakers should also make good English an essential qualification at the apprentice and journeyman stages of learning the craft. Phill ___ 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: I-D file formats and internationalization
Hallam-Baker, Phillip wrote: SNIP previous posters text It might seem odd to people whose names do fit in ASCII but there are a lot of people who care about this type of issue. You can of course publish drafts and RFC's as XML which supports any character set you want. SNIP The IETF has had the attitude 'this is the way we do things here, nobody asked you to like it'. It would be better to state: if you don't like it, participate. Because if you didn't participate, then don't complain that it isn't like you wanted it to be. Yes that requires significant effort, time and thus cash, but that is mostly unavoidable. So far 700 translations of W3C specifications have been made by SNIP One can always start translating RFC's: 4267 RFC's and a long list of drafts to go, though there is a lot of material already translated by book authors. Note that many languages don't have translations for many English words. German is one of the good examples where they have a lot of German versions of English words, but they don't have one for 'Hyper Text Transfer Protocol' unless you babelfish it to Hyper Text-Übergangsprotokoll*, which is far from a useful translation. There is also the thing that sentence construction might cause misinterpretation from what the original working group meant. SHOULD and MUST both translate to Muß in German, which is thus not correct either. This can cause many issues. And German is somewhat in the same line as English, I am not even thinking in the area of Asian languages, which I unfortunately am far from familiar with except that they resemble small pictures of what they mean. I don't think it is a task for the IETF itself to translate documents. But it would indeed be nice to have a place for them, with a big note that they have not been verified and may include odd translations. Maybe there could be a separate 'translated documents' section? Greets, Jeroen * contains a U-umlaut (Uuml;) and Ringel-S (szlig;) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Making the xml source available is a boon for those working on subsequent revisions of a document. Many of the RFCs and I-Ds I've worked on have been derivative of earlier RFCs, and having an authorative source format available helps that considerably. Since I grok nroff, I've been able to make good use of the nroff source on occasion, and the RFC Editors have sometimes (in non-crunch-time situations) been quite happy to provide that. I'd much prefer having the source files available at all times so I didn't have to ask them, or make do without during those crunch times. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Just as a rough data point and to second Tony's note, I count about 120 active Internet drafts that are labeled '*bis*'. There are probably many more that don't follow this naming convention. All of these are presumably based on earlier published documents. Tony Hansen wrote: Making the xml source available is a boon for those working on subsequent revisions of a document. Many of the RFCs and I-Ds I've worked on have been derivative of earlier RFCs, and having an authorative source format available helps that considerably. Since I grok nroff, I've been able to make good use of the nroff source on occasion, and the RFC Editors have sometimes (in non-crunch-time situations) been quite happy to provide that. I'd much prefer having the source files available at all times so I didn't have to ask them, or make do without during those crunch times. Tony Hansen [EMAIL PROTECTED] ___ 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: XML2RFC submission (was Re: ASCII art)
On Nov 29, 2005, at 1:53 PM, Gray, Eric wrote: One issue with to quickly responding to Bob's earlier questions is that the XML version - as Christian has already said - cannot be the authoritative/normative version of an RFC. I would qualify that someone by allowing that an XML version cannot be authoritative/normative unless it is completely self contained. And, by self contained, I mean there MUST be an absolute, positively concrete guarantee that every time we process it, it will always produce exactly the same text. The value in retaining input files used to generate the authoritative/ normative version of an RFC is to facilitate subsequent updates. While the bibliography section could be seen as dynamic for an ID, RFC references will provide static results. Boilerplates provided within conversion tools help expedite conformance to current requirements. What problem is created considering the XML version of the draft as non-authoritative? Nevertheless, some effort should be made to manage the bibliography reference library related to the IETF, to ensure consistent conversions. An additional benefit could be seen as permitting a larger diversity of output formats. While indeed the current ASCII text RFCs may be suitable vehicles for conveying information, they lack convenience such as hyper-links to reference information. The current XML2RFC tools provides for both the text and HTML output forms of this document. It would not be difficult to include a PDF output that also provides hyper-link capabilities. Full graphic capabilities may not be a desired goal, as a million words may still be required to clarify the intent of a complex picture. In nearly all RFCs, the artwork offering tables describing the format of binary structures offers the greatest benefit. ASCII artwork may not draw perfect lines, but this is really a matter of character-sets. Should the IETF consider definitions to cover optional characters for drawing table borders and lines? Does this get extended into also allowing international characters for author's names? Clearly an XML input file allows for a greater diversity of outputs. Perhaps, with some effort, more than just the text form of the RFC can be considered authoritative. The XML input would not need to be considered authoritative to achieve such a goal. Allowing access to these XML documents will reduce the burden on authors attempting to make corrections and highlighting what changes are being made, beyond the boilerplates and format changes, etc. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Update: IETF Trust Consensus Call
Greetings - In response to concerns raised about the licensing provisions described in section 9.5 of the IETF Trust the Settlors have agreed to modify the language as follows: 9.5 Licenses. The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR other than rights in IETF standards-related documents (such as RFCs, Internet Drafts and the like) that have been acquired by the Trust through non-exclusive licenses granted by their contributors pursuant to the IETF community-approved procedures currently set forth in RFC 3978, and any community-approved updates and revisions thereto, shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have or claim in any derivative works of licensee that are based on or incorporate the IPR, and (b) the licensee's use of the IPR and any goodwill associated therewith shall inure to the benefit of the Trust. Including the reference to RFC 3978 and future community updates with regard to standards related documents should make clear our intentions and provides the cleanest way to ensure that the communities concerned our addressed directly by the founding document. The IAOC thanks the Settlors for moving quickly to adopt this language. Please send questions or comments to: ietf@ietf.org or [EMAIL PROTECTED] Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
Robert Sayre wrote: I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. http://tools.ietf.org/html/draft-hoffman-utf8-rfcs I really don't like this approach for various reasons. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
On Nov 30, 2005, at 12:41 PM, Frank Ellermann wrote: Robert Sayre wrote: I'm sure someone has already suggested this approach, but I'll add my voice to the chorus. http://tools.ietf.org/html/draft-hoffman-utf8-rfcs I really don't like this approach for various reasons. Rather than opening RFCs to text utilizing any character-set anywhere, as this draft suggests, there could be alternative UTF fields for an author's name and reference titles, and perhaps defined characters for simple line and table drawing that invoke automatic translation when an ASCII text version is generated. Being able to review the ID as it would appear as an RFC would also seem to be a requirement. It seems problematic for protocol examples to use non- ASCII characters owing to there not being ubiquitously displayable character-sets. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
* occasion, and the RFC Editors have sometimes (in non-crunch-time * situations) been quite happy to provide that. I'd much prefer having the * source files available at all times so I didn't have to ask them, or * make do without during those crunch times. * Tony, As far as we know, the RFC Editor has never failed to promptly provide nroff source for published RFCs to any who request it. Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
* * Unicode support is a different matter. I find the current * IETF policy to be incredibly bigoted. Many RFCs and I-Ds are * currently forced to misspell the names of authors and * contributors, which doesn't seem like correct attribution to * me. So, I recommend that the IETF secretariat and the RFC * Editor change their policies to allow UTF-8 text files. That * way, older RFCs and I-Ds produced using the current tools * would follow the same encoding. This issue has been brought up before and has been on our list of things to worry about for at least two years. But we always run aground on the following consideration: there is a substantial constituency for have some least-common-denominator form of IETF documents, so people can read and print them with even the most primitive, old-fashioned (unfashionable?) tools. Allowing extended character sets for author names seems like a really nice idea to the RFC Editor as well, but we see no way to do that and keep the LCD. You need some kind of structured document that some people won't have the tools to display, search, print, ... The RFC Editor would welcome a way out of this dilemma. It is not bigotry, only realism. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
At 1:54 PM -0800 11/30/05, Douglas Otis wrote: http://tools.ietf.org/html/draft-hoffman-utf8-rfcs Rather than opening RFCs to text utilizing any character-set anywhere, as this draft suggests, That is not what the RFC suggests at all. The character set is Unicode. The encoding is UTF-8. That's it. there could be alternative UTF fields for an author's name and reference titles, and perhaps defined characters for simple line and table drawing that invoke automatic translation when an ASCII text version is generated. That's a possibility (if you define what an alternative UTF field is). Why is it better than simply using UTF-8 everywhere? Being able to review the ID as it would appear as an RFC would also seem to be a requirement. That means changing the Internet Drafts process as well. Certainly possible, but more daunting that changing one process at a time. It seems problematic for protocol examples to use non-ASCII characters owing to there not being ubiquitously displayable character-sets. Unicode is universally displayable if you have the right font(s). Regardless of that, however, any sane document author would not assume that every person reading the document could display it. They would put a legend or explanation near the example. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
Douglas Otis wrote: there could be alternative UTF fields for an author's name and reference titles, For the new 3066bis language tags registry we adopted the known #x12345; notation for u+012345. As Bob said raw UTF-8 characters won't fly with `cat rfc4567 /dev/lpt1` and other simple uses of RFCs. perhaps defined characters for simple line and table drawing Ugh. That's a case where I'd prefer PDF or something better. ASCII art is one thing, IMHO it's cute. But line drawing char.s are a PITA: my local charset pc-multilingual-850+euro still has this, today it's just crap, let's forget it please, codepage 437 etc. and curses ACS_* are ancient history. Ok., in theory Unicode has these characters, but if we'd really want this we could as well jump from plain text to MathML. It seems problematic for protocol examples to use non-ASCII characters owing to there not being ubiquitously displayable character-sets. Yes, OTOH I vaguely recall one of Martin's (?) texts, where his attempt to talk about non-ASCII issues in ASCII wasn't straight forward, to put it mildly, and it certainly wasn't his fault. Similar texts published by the W3C using UTF-8 are even worse from my POV (both with a pre-UTF-8 browser and otherwise, for the latter I just don't have the required fonts). Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Why are we so exceptional [was: Translations of standards (was: RE: ASCII art)]
At 19:59 30/11/2005, Burger, Eric wrote: Wouldn't having quasi-authoritative translations *result* in balkanization? No. The current system leads to balkanization: - exclusively ASCII standards call for translation. Since there is no possible cross-verification, the understanding may diverge. - the local practices stay unknown to the IETF. We need to build bridges, not to exclude, and to permit cross-verification. The first step is to have a common naming of the common references. Only bi-lingual people will be able to cross-verify, but we only need three of them to have a reasonably cross-verification of the texts and of the auditors. IRI-tags can permit that. Today an RFC cannot even quote a non-English reference. The next step is to be able to integrate in the IETF authoritative BCPs, quotes of locally authoritative rules. Not to change them. We must not translate the normative quote (a translation should always be informative). This calls for the support of UTF-8. Otherwise the IETF creates the balkanization it wants to avoid (it cuts itself from the rest of the world). The Chinese National Standard series comes immediately to mind of authoritative translations *with interpretations*. I note that the best protection against interpretations is multilingualism. If you have a version in English and a version in Chinese, it is difficult to say which is to be used as a reference (as Vint says, is authoritative the most accepted understanding - a basic brainware rule) - so the Chinese standard will soon be the referent. But if you have a version in French, in German, in Russian, in Arabic, etc. and only one says something different, common sense will prevail (and we will be able to analyse why, what may lead to new developments). nal Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JFC (Jefsey) Morfin Sent: Monday, November 21, 2005 8:08 PM To: ietf@ietf.org Subject: Why are we so exceptional [was: Translations of standards (was: RE: ASCII art)] At 20:49 21/11/2005, John C Klensin wrote: --On Monday, 21 November, 2005 11:16 -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I think that a better case to make wrt internationalization is that it is hard to see how a pure ASCII document is ever going to provide a satisfactory description of a protocol that is based on unicode. This is an entirely different issue from the one that I think Jefsey was raising and Tom was responding to. Conflating them gets us nowhere at all. I commented Paul Hoffman's response to Julien Maisoneuve about why we are so exceptional. Nothing else. May be should I have changed the subject. This is now done. And that takes us back to Paul's original comment, at least as I understood it -- the important thing is the quality of the writing. Access to fancy formatting and presentation tools may make good writing easier to follow and, in particular, to let the reader get the gist of what is going on before trying to deeply study the text. But adding fancy formatting and presentation to poor writing will, at best, only hide, for a while, the fact that the explanations are inadequate. Agreed. But I hope you do not imply non-ASCII English is fancy formatting and goes with inadequate explanations. And, by not forcing the extra discipline that writing without a dependence on clever illustrations requires, it may make it more likely that we will get documents whose inadequacies are harder to detect. ASCII Draft is not the main point here. But it is true that a good draft often speaks more than long texts. As I said, that conclusion could change as experience with protocols based on Unicode expands. But, so far, we have almost no experience along that dimension (and, incidentally, neither do ISO or ITU or IEEE, at least as far as I know). I have no idea of what are protocols based on Unicode. I only know that equal linguistic opportunity and common global interest mean that authoritative protocols and procedures should be producible in every language and aggregated into the IETF document body. Not fully permitting this would only increase the risks of balkanization of the Internet. jfc ___ 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: I-D file formats and internationalization
On Nov 30, 2005, at 2:23 PM, Paul Hoffman wrote: At 1:54 PM -0800 11/30/05, Douglas Otis wrote: Rather than opening RFCs to text utilizing any character-set anywhere, as this draft suggests, That is not what the RFC suggests at all. The character set is Unicode. The encoding is UTF-8. That's it. Unicode provides a unique number for every possible character within a current range of about 97,000 characters. These characters include punctuation marks, diacritics, mathematical and technical symbols, arrows, dingbats, etc. Displaying one of these characters requires a character-set (synonymous with a display system's font-set or character-repertoire), or using the unicode vernacular, a script. It is not just a matter of which character is displayed, which character- repertoire is used, but there are also Middle Eastern right-to-left issues as well. there could be alternative UTF fields for an author's name and reference titles, and perhaps defined characters for simple line and table drawing that invoke automatic translation when an ASCII text version is generated. That's a possibility (if you define what an alternative UTF field is). Why is it better than simply using UTF-8 everywhere? Such alternative field could be an added element to the DTD or Schema defining the XML input document. When the output is other than ASCII, the alternative field could be displayed. To allow compatibility with existing tools, the ASCII version would not be affected. Permitting access to _some_ extended characters could improve upon the quality of some line-drawing for non-ASCII outputs. To avoid the pain-in-the-ass issue, improved drawings could be generated by a simple web based drawing application, where the translation back into ASCII artwork would be straight-forward, and yet provide comparable results. Currently, improved graphics are limited to the generation of HTML tables. The drawing application could even create the needed XML wrapper for an RFC. Being able to review the ID as it would appear as an RFC would also seem to be a requirement. That means changing the Internet Drafts process as well. Certainly possible, but more daunting that changing one process at a time. As an ID becomes an RFC, it seems expecting last minute changes to the document would be even more daunting. It seems problematic for protocol examples to use non-ASCII characters owing to there not being ubiquitously displayable character-sets. Unicode is universally displayable if you have the right font(s). Regardless of that, however, any sane document author would not assume that every person reading the document could display it. They would put a legend or explanation near the example. Assume such characters can not be displayed, at least not with the ASCII version that excludes the extended character-set allowed by unicode. An escape mechanism would be needed to accommodate alternative text, where displaying '?' for the unicode characters that extends beyond ASCII would not be a very satisfactory solution, as this would make the ASCII version less authoritative, to say the least, and break the way many use the RFC text files. I liked the idea that Frank suggested, use the HTML escape sequence to declare the unicode character. This allows the ASCII version to remain authoritative. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D file formats and internationalization
At 5:59 PM -0800 11/30/05, Douglas Otis wrote: On Nov 30, 2005, at 2:23 PM, Paul Hoffman wrote: At 1:54 PM -0800 11/30/05, Douglas Otis wrote: Rather than opening RFCs to text utilizing any character-set anywhere, as this draft suggests, That is not what the RFC suggests at all. The character set is Unicode. The encoding is UTF-8. That's it. Unicode provides a unique number for every possible character within a current range of about 97,000 characters. These characters include punctuation marks, diacritics, mathematical and technical symbols, arrows, dingbats, etc. Displaying one of these characters requires a character-set (synonymous with a display system's font-set or character-repertoire), or using the unicode vernacular, a script. It is not just a matter of which character is displayed, which character-repertoire is used, but there are also Middle Eastern right-to-left issues as well. It may be better to use a single vocabulary for discussing things such as internationalization and character sets. That's the purpose of RFC 3536. Being able to review the ID as it would appear as an RFC would also seem to be a requirement. That means changing the Internet Drafts process as well. Certainly possible, but more daunting that changing one process at a time. As an ID becomes an RFC, it seems expecting last minute changes to the document would be even more daunting. Yep, that's the tradeoff. We already make some automatic changes after in Internet Draft is approved by the IESG, and we allow others without IESG oversight. This would be another class. That scares some people, and not others. Having Internet Drafts use Unicode in UTF-8 instead of ASCII scares some people, and not others. It seems problematic for protocol examples to use non-ASCII characters owing to there not being ubiquitously displayable character-sets. Unicode is universally displayable if you have the right font(s). Regardless of that, however, any sane document author would not assume that every person reading the document could display it. They would put a legend or explanation near the example. Assume such characters can not be displayed, at least not with the ASCII version that excludes the extended character-set allowed by unicode. An escape mechanism would be needed to accommodate alternative text, where displaying '?' for the unicode characters that extends beyond ASCII would not be a very satisfactory solution, as this would make the ASCII version less authoritative, to say the least, and break the way many use the RFC text files. No escape mechanism is needed. Non-displayable characters are still in the RFC, they simply can't be displayed by everyone (but they can be displayed by many). This is infinitely simpler, and a much better long-term solution, than an escape mechanism. Further, there would be no more ASCII version to be authoritative. The Internet Draft clearly says that there is a single RFC, and it has a single encoding. I liked the idea that Frank suggested, use the HTML escape sequence to declare the unicode character. This allows the ASCII version to remain authoritative. ... as well as unreadable and unsearchable using normal search mechanisms. The purpose of the proposal is to allow RFCs to be readable and searchable using the encoding that is common on the Internet, without resorting to sorta-kinda-HTML or an escape mechanism. Remaining with plain ASCII would be better than either of the latter. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Internationalization by ASCII art (was Re: I-D file formats and internationalization)
Robert Sayre wrote: Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. It is your stupidity that you can't recognize peoples' names correctly represented in ASCII. See how widely non-ASCII domain names and mail addresses are used. However, if you insist, you may use ASCII art. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internationalization by ASCII art (was Re: I-D file formats and internationalization)
On 11/30/05, Masataka Ohta [EMAIL PROTECTED] wrote: Robert Sayre wrote: Unicode support is a different matter. I find the current IETF policy to be incredibly bigoted. Many RFCs and I-Ds are currently forced to misspell the names of authors and contributors, which doesn't seem like correct attribution to me. It is your stupidity that you can't recognize peoples' names correctly represented in ASCII. Well, I'm not the sharpest knife in the drawer, but Google is even duller than I am. Anyway, I'm wondering what all the command line whinging is about, since I came home from work and tried some command line tools on http://www.cl.cam.ac.uk/~mgk25/ucs/examples/quickbrown.txt. I tried cat, vi/vim, more/less, and pico/nano on Ubuntu Linux 5.10. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4245 on High-Level Requirements for Tightly Coupled SIP Conferencing
A new Request for Comments is now available in online RFC libraries. RFC 4245 Title: High-Level Requirements for Tightly Coupled SIP Conferencing Author(s): O. Levin, R. Even Status: Informational Date: November 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 24415 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-sipping-conferencing-framework-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4245.txt This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4245.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Correction: RFC 4267 on The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/p
A new Request for Comments is now available in online RFC libraries. RFC 4267 Title: The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml Author(s): M. Froumentin Status: Informational Date: November 2005 Mailbox:[EMAIL PROTECTED] Pages: 9 Characters: 17753 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-froumentin-voice-mediatypes-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4267.txt This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4267.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Impending publication: draft-iab-irtf-01.txt
The IAB is ready to ask the RFC-Editor to publish IAB Thoughts on the Role of the Internet Research Task Force (IRTF) draft-iab-irtf-01.txt as an Informational RFC. The chief purpose of this document was to collect and record a set of considerations the IAB discussed in the process of reviewing the IRTF Chair position last year. As such, it is not suggesting process or structure changes at this time, and is primarily intended to capture IAB state. Comments are therefore most likely to be of the form of suggestions for improving clarity. The IAB solicits comments by December 14, 2005. Please send comments to the IAB (iab@iab.org), or to [EMAIL PROTECTED] The document can be found at http://www.ietf.org/internet-drafts/draft-iab-irtf-01.txt From the Abstract: This document is an IAB (Internet Architecture Board) report on the role of the IRTF (Internet Research Task Force), both on its own and in relationsip to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. Leslie Daigle, For the IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
