RE: RFC archival format, was: Re: More liberal draft formatting standards required
OK, here is what happens on my netbook using your method. Original 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | Type |L ength |R|T| Transpor t flags | Res | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
... and don't get me started on LaTeX. I am not sure what problems you had with LaTeX, but as someone who has written thousands of pages using TeX, I can't imagine anything better for professional document preparation. On the other hand, the learning curve is relatively steep, and its full power is not needed for the plain text documents that most people participating in this thread seem to be writing. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
On 2009-7-5, at 16:20, Carsten Bormann wrote: Would it help to simply call it 1.34 now? (Then it would be picked up by distributions and packaging services such as macports, and people could stop installing by hand.) +1 I maintain the fink package for xml2rfc, and the committers asked me to wait for the stable release instead of sending them ports for pre releases (the pre releases don't fit well with the regular fink naming scheme and hence require manual tweaking, which they want to avoid.) Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 6 jul 2009, at 09.01, Yaakov Stein wrote: ... and don't get me started on LaTeX. I am not sure what problems you had with LaTeX, but as someone who has written thousands of pages using TeX, I can't imagine anything better for professional document preparation. On the other hand, the learning curve is relatively steep, and its full power is not needed for the plain text documents that most people participating in this thread seem to be writing. Problem with LaTeX and TeX is the need for class libraries, and the lack of agreed upon way of distributing a LaTeX/TeX file with the class files needed (part from what is standard), or lack of automatic tools that include needed things from the class files to the source file. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
Hi, On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. since you asked: I have absolutely no problems with xml2rfc. I used to edit in nroff, which wasn't compatible with my brain, and I used Joe's Word template, which works OK, but I prefer something ASCII- based for collaborative editing (for svn, diff, etc.) I'm fully open to trying something new once someone creates a different (better) tool, but until then, xml2rfc is OK. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Jul 5, 2009, at 05:02, Phillip Hallam-Baker wrote: On Jun 29, 2009, at 16:22, Phillip Hallam-Baker wrote: It is not the height of the barrier, it is the perception that people are making nit-picking objections for the sake of rubbing people's noses in the fact that they can decide where to put the bar. [my piquant comment elided for space] Lets unpack this argument: In the serious publishing world there are editors who review prose and nit pick. Therefore all nit picking is evidence of serious publishing and all criticism comes from 'unpublishable wankers'. I don't want to go that far. Let me revise my remarks: the perception of editors making seemingly arbitrary objections about *manuscript formatting*, primarily for the purpose of rubbing the noses of prospective authors in their own plebeianness, is a very common trait among unpublishable wankers. (Being an unpublishable wanker myself still, I'm speaking from experience *and* close observation of my peers.) Shorter james: I'll need to be convinced that perception is fair before I can join in the pillorying of our I-D submissions system maintainers. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, 2009-07-05, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. Original 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | Type |L ength |R|T| Transpor t flags | Res | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ What sort of editable input, handled by what sort of presentation mechanism, would solve this case? And, if it involves horizontal scrolling and/or zooming in or out, why wouldn't that also handle plain text, too? -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 8:53, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ Hm, it's not supposed to break lines between pre and /pre even if they don't fit on the screen... Obviously ASCII art is created with screen / paper size assumptions built in. I never claimed I was able to get around that. My claim was that it was possible to create an HTML-ized form of the RFC format that would both be valid HTML and could be turned back into the well- known plain ASCII format by simply removing the HTML tags. Due to the difficulties in making good graphics and the issue of having a single RFC span multiple files in the case of HTML format with graphics I think we should stick with ASCII art in the general case even if we move to HTML as the archival format. But packet layout diagrams can be made with HTML tables, which would make them a little more flexible than ASCII art but on a really tiny screen those still wouldn't display very well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
Lars Eggert wrote: Hi, On 2009-7-5, at 16:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. since you asked: I have absolutely no problems with xml2rfc. I used to edit in nroff, which wasn't compatible with my brain, and I used Joe's Word template, which works OK, but I prefer something ASCII-based for collaborative editing (for svn, diff, etc.) I'm fully open to trying something new once someone creates a different (better) tool, but until then, xml2rfc is OK. Indeed. Also, we should keep in mind that xml2rfc can refer both to a specific XML vocabulary, and a set of tools. The vocabulary is relatively straightforward, and has been extended by both MTR and others. At some point of time, we may want to work on a revision of it (that is, RFC 2629). With respect to the tools: I usually do not worry about xml2rfc.tcl (the processor) until I need to submit something. Instead, I make sure that my source validates (against the DTD), and instead focus on content, and just review the HTML output, as produced by rfc2629.xslt. The latter works on any machine that has support for XSLT, such as any that can run IE6, Firefox 2, Opera 9, or Safari 3. And no, you don't need a browser to run the XSLT, just install xsltproc or Saxon. Finally, regarding local installations of xml2rfc.tcl: at least on Windows, just install Cygwin, make sure TCL is included in the install, and it will work just fine. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray wrote: On Sun, Jul 5, 2009 at 9:05 AM, Melinda Shoremelinda.sh...@gmail.com wrote: You're heading into new territory, here. No, I disagreed with an unqualified assertion you made using the extremely well-defined termASCII. Sure, you are. You're implying that there are characters we want to display that can't be done within the current constraints. I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. I've never run into a device that can't display ASCII at all (if it can display HTML it can display plain ASCII), but have used and owned a large number of devices that can't display HTML. Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
On Mon Jul 6 08:46:24 2009, Julian Reschke wrote: Also, we should keep in mind that xml2rfc can refer both to a specific XML vocabulary, and a set of tools. The vocabulary is relatively straightforward, and has been extended by both MTR and others. At some point of time, we may want to work on a revision of it (that is, RFC 2629). The vocabulary is basically sound. I sympathize with Iljitsch wanting finer control over the rendering of his name, which would need to be addressed here. If a GUI WYSIWYG tool got created, I'd probably use it. If someone created an import filter for some word processor or another, I might use it, but I generally don't get on with word processors anymore. (I had an argument with one a few years ago, we never made up). With respect to the tools: I usually do not worry about xml2rfc.tcl (the processor) until I need to submit something. Instead, I make sure that my source validates (against the DTD), and instead focus on content, and just review the HTML output, as produced by rfc2629.xslt. The latter works on any machine that has support for XSLT, such as any that can run IE6, Firefox 2, Opera 9, or Safari 3. And no, you don't need a browser to run the XSLT, just install xsltproc or Saxon. I do much the same, although because the document is in XML, I use a slightly extended format to include annotations to support finer reference handling and checking, which I scribbled some time back in XSLT. It gives me an extra stage to my processing, and annoys co-authors, but produces documents I know have the right references in the right sections. XML purists will probably wail and gnash teeth, since I replaced the inclusion handling very early on with something probably even worse than the include PI, but that's the joy of XML. Finally, regarding local installations of xml2rfc.tcl: at least on Windows, just install Cygwin, make sure TCL is included in the install, and it will work just fine. There are also online versions, which eliminate the need to install it at all if you've got bandwidth. I'm quite sure that both the file format and toolset could improve, but I thinks it's a very reasonable way of processing drafts as it is, and I've be very happy if it were eventually the only way. FWIW, I suspect that the way I'm doing things - with an initial format and using the RFC 2629 format as an intermediate one - is probably the rough shape of things to come. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Melinda Shore wrote: ... I don't think that the second part of your assertion is correct. I'm not trying to be difficult. I introduce by example the huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all. I've never run into a device that can't display ASCII at all (if it can display HTML it can display plain ASCII), but Some EBook readers, as far as I recall, display XHTML fine, but do not display plain text. And even if they do, you will encounter the line wrap problem. have used and owned a large number of devices that can't display HTML. Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. ... Of course that depends on the type of HTML we would use. For instance, if you get inconsistent results with the HTML my XSLT variant of xml2rfc produces, please let me know (example: http://greenbytes.de/tech/webdav/rfc2616.html). BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Colin Perkins wrote: I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. +1 ... and I am quite happy to use the online compiler. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Paul It appears that people have forgotten that, when needed for clear artwork, RFCs can be published in PDF format. This has been done in the past, and can be done again in the future. If WGs are not doing some work because of fear of not having it published as an RFC because of the artwork, they are working under a misconception. Talk about premature anti-optimization! We know this, the problem is that you cannot publish a standards track document in this format. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 12:08, Melinda Shore wrote: Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. I disagree with 2. Today, drafts and RFCs have a fixed format, that should render the same on all displays and in print (barring font differences, but I guess Courier is assumed). Although this format isn't particularly pretty and current mainstream tools can no longer create it, this format has a lot going for it: - pretty much everything that can classified as a computing device can display it natively - should the need arise to write an implementation for display software from scratch, that would be extremely trivial - no issues with copy/paste - compatible with lots of tools However, it has one big issue: it doesn't adapt to the properties of the display gracefully. (Or at all, really.) This is the part that would be easy to fix by adopting a very basic flavor of HTML. This would give us line wrap and the ability to use tables, but we'd lose the headers/footers. ASCII art could still be used as preformatted text. This type of basic HTML will render slightly differently on different implementations, but that's the point. Unless technical meaning is encoded in spaces and line breaks, this shouldn't matter. And even in basic HTML, it's possible to add class specifications etc that allow tools to apply more intelligence than would be possible with plain text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: ... This is the part that would be easy to fix by adopting a very basic flavor of HTML. This would give us line wrap and the ability to use tables, but we'd lose the headers/footers. ASCII art could still be used ... Headers/footers will work just fine with a HTML client that supports the CSS3 paged media extensions; for now that's only PrinceXML (http://www.princexml.com/), but it's a start. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Iljitsch, On Sun, 2009-07-05 at 15:24 +0200, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I had my first experience with xml2rfc recently, and I largely agree. It's easy to totally screw up a document by misplaced XML, xml2rfc doesn't handle non-ASCII very well (important for some names), the error output is non-intuitive, the tool didn't work off-line (no fun on an airplane), and so on. It seems to get in the way of writing the actual draft. Maybe there is no better way, but it seems hard to believe. (I am more willing to believe that there is no better way *now*, but that one may be found in the future.) Making it harder on authors (of which we seem to have plenty) in order to make things easier on editors and reviewers (which seem in short supply) may be the right trade-off. -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Shane Kerr wrote: ... I had my first experience with xml2rfc recently, and I largely agree. It's easy to totally screw up a document by misplaced XML, xml2rfc Yes. doesn't handle non-ASCII very well (important for some names), the error That's an IETF doc format restriction, not an xml2rfc problem per se. output is non-intuitive, the tool didn't work off-line (no fun on an airplane), and so on. It does work offline, unless your source requires non-local files (like external references). ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
I *strongly* support please don't ever *mandate* it [XML2RFC]. Although, I'm perfectly happy using the obscure syntax of nroff (when combined with a set of macros I received from George Swallow about 10-12 years ago). I produced a couple of drafts using xml and decided that nroff was much easier and let me focus on the the document rather than the document production... Lou On 7/5/2009 7:25 PM, Hadriel Kaplan wrote: At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. +1 For those who are used to MS-Word, XMLMind is frustrating and truly requires an XML mind. Even simple things like cut/paste are done in a very different (and frankly inconsistent) way, as are references and such. In theory a WYSIWYG word processor shouldn't require an author to know the internal representation and underlying language of the document format. I know a large number if not outright majority of IETF authors do not use MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and force the rest of us have to write documents in a syntax only a tiny fraction of the planet uses and understands. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
On Sun, Jul 05, 2009 at 03:20:20PM +0200, Carsten Bormann wrote: To me, 1.34pre3 appears to be exactly as stable as 1.33 (modulo the instability inevitably introduced by the 5378 train wreck). I have actually run into a somewhat cryptic error message (which I was unable to reproduce on earlier releases, but which I was also unable to reproduce consistently anyway), and I've seen some other reports of issues with 1.34pre3, so it appears there are some dust bunnies in the corners. If I knew anything at all about TCL, I'd probably try to do more work on it, but as it is I'm just grateful that those who work on xml2rfc do as good work as they do. (That isn't to say that there isn't an issue here with process, but as I already that is not a criticism of the xml2fc developers.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. I was ignoring it and hoping it went away. ;-) I started off using the MS Word template and CRLF to output txt documents. I found this to be a PITA. About 9 months ago I switched to xml2rfc and found it to be great. Yes, it had a learning curve and the error messages could be better, but the learning curve is not terrible IMHO and you eventually get to figure out what the errors mean after awhile. My productivity gains in writing and editing drafts is much higher than with MS Word, though I miss some of Word's built-in change acceptance/rejection functionality (doing an xml diff is fine, just different). I also love being able to define both external links and internal anchors so easily. Just the internal reference linking has saved me time in post version -00 docs when I move sections or sentences around and needn't worry about keeping track of what section was what number. And it is also nice to be able to share an HTML version of the doc with co-authors and reviewers, rather than a txt doc with no working links. I happen to use Coda on the Mac and use it to write HTML and other scripting stuff. YMMV. No, it's not. The problem with XML2RFC formatted drafts and RFCs is that you can't display them reasonably without using XML2RFC, and although XML2RFC can run on many systems in theory, in practice it's very difficult to install and run successfully because it's written in TCL and many XML2RFC files depend on the local availability of references. When those aren't present the conversion fails. How frequently do any of us work when we're not connected to the Internet? I just have my XML editor open in one window and the web-based xml2rfc tool in the other, and every time I make a significant change, I just re-run it to display an HTML version of the document. This tends to also make error-investigation easier since I know what I just changed and can then review a specific section to find my error. those tools. So I write my XML2RFC source by hand. The result is that I invariably get error messages that the section and /section tags don't match properly. This is a problem that is extremely hard to debug manually, especially as just grepping for section isn't enough: there could be a !--, --, /middle etc somewhere between a section and /section that breaks everything. This is most likely a nested section tag problem. When you write your XML do you have every flat and justified left? If so, I'd recommend you tab-in sections and keep your open and close tags lined up, as well as any tags within each section tabbed in further. What we need is the ability to write drafts with a standard issue word processor. You mean like the template and directions available for MS Word? Why not just use that? Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
We know this, the problem is that you cannot publish a standards track document in this format. Stewart This is not quite true... at least, it never used to be true. The restriction is/was that only the .txt version is normative; a .pdf version is non-normative and intended for explanatory material. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
Lars since you asked: I have absolutely no problems with xml2rfc. I find that xml2rfc takes too much control over the boilerplate and the references to be a really useful tool. I dropped it after one attempt. However, many of my colleagues use it, and as a result I've gotten many questions of the form what do I have to do to make xml2rfc produce output that will pass idnits?. I can't tell them just put in the following boilerplate, instead I've had to figure out the right value of the ipr variable. (BTW, no one ever cares what the boilerplate actually says, just whether it will pass idnits; xml2rfc really encourages folks to ignore the semantics of the boilerplate.) Joel One large draft I was working on was originally written using WORD. I Joel found it extremely difficult to work with (although I have a current Joel version of Word available at all times.) Instead, working with Joel another author we converted the document to XML for XML2RFC. Hey, I've converted from both Word and XML to nroff; that way I don't get any surprises ;-) OTOH, I have to admit that nroff was a bit challenging when I moved from Solaris to Linux. Joel I have seen some folks arguing that we should make XML2RFC normative Joel and mandatory. Of course, in the IETF it is very common for folks to think that their personal preferences are objectively superior. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
At 6:56 AM -0700 7/6/09, Bob Braden wrote: This is not quite true... at least, it never used to be true. The restriction is/was that only the .txt version is normative; a .pdf version is non-normative and intended for explanatory material. This is my understanding as well (I can't find an RFC that says one way or another, but I could have missed it). We have recent full-worked examples where the PDF for a standards-track document has valuable visual information, such as RFC 5059. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all HTML is a good presentation format, but as an archival format it seems to leave a lot to be desired, as the included links always seem to go stale. Also, I don't think that the notions of page numbers and table of contents have quite reached the status of quaint and archaic. large number of standard office printers that print HTML instantly and correctly My experiences printing HTML docs are a bit different, I guess. Is there no tool that will html-ize an RFC or i-d for presentation? Folks who want to read RFCs on their cell phones should be able to do it, but I really don't see what that has to do with archival formats. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
On Jul 6, 2009, at 15:28, Andrew Sullivan wrote: I have actually run into a somewhat cryptic error message (which I was unable to reproduce on earlier releases, but which I was also unable to reproduce consistently anyway), and I've seen some other reports of issues with 1.34pre3, so it appears there are some dust bunnies in the corners. While I'm certain there are some dust bunnies, I'm nearly certain they are the same as with 1.33. There simply aren't that many changes. 1.34pre3 is certainly working for people doing drafts these days. 1.33, however, is utterly useless! Ship it. (Maybe after removing the one remnant test output in the nroff rendering code on line 12106.) Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Eric Rosen wrote: huge number of mobile devices that handle HTML effortlessly and IETF legacy ASCII not at all HTML is a good presentation format, but as an archival format it seems to leave a lot to be desired, as the included links always seem to go stale. ... But that's a problem of the link targets, not the document format, right? large number of standard office printers that print HTML instantly and correctly My experiences printing HTML docs are a bit different, I guess. In generic, or HTML as produced by tools.ietf.org, xml2rfc, or rfc2629.xslt? ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
+1!! Carsten Bormann wrote: 1.34pre3 is certainly working for people doing drafts these days. 1.33, however, is utterly useless! Ship it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
Eric Rosen wrote: Lars since you asked: I have absolutely no problems with xml2rfc. I find that xml2rfc takes too much control over the boilerplate and the references to be a really useful tool. Given how extensive and strong the support for using it is, your assertion is demonstrably incorrect. On the other hand, that some folk might not like using it is demonstrably correct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Paul, Section 2.4 of 2223bis (www.rfc-editor.org/rfc-editor/instructions2authors.txt) says: The ASCII plain text version (and its .txt.pdf facsimile) is always the official specification, and it must adequately and completely define the technical content. ... The primacy of the ASCII version typically requires that the critical diagrams and packet formats be rendered as ASCII art in the .txt version. However, secondary or alternative versions in PostScript and/or PDF are provided for some RFCs, to allow the inclusion of fancy diagrams, graphs, or characters that cannot possibly be rendered in ASCII plain text Bob Braden for the RFC Editor Paul Hoffman wrote: At 6:56 AM -0700 7/6/09, Bob Braden wrote: This is not quite true... at least, it never used to be true. The restriction is/was that only the .txt version is normative; a .pdf version is non-normative and intended for explanatory material. This is my understanding as well (I can't find an RFC that says one way or another, but I could have missed it). We have recent full-worked examples where the PDF for a standards-track document has valuable visual information, such as RFC 5059. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Paul is correct. I-D Submission in quite intentionally less strict. I have been out of the office and away from email for the last week, and as a result, I have not fully caught up on this thread. However, there are some things that seem to need clarification. http://www.ietf.org/ietf/1id-guidelines.html This web page provides guidelines for I-D submission. While the vast majority of the information in it is correct, It needs to be updated. The author has just been too busy to do the update. http://www.ietf.org/ID-Checklist.html This web page provides the things that are checked by the IDnits tool which is used as part of the online submission checking. I have personally prepared an I-D and checked it with the IDnits running on tools.ietf.org an then had it rejected by the online submission tool. I have asked the Secretariat to work with Henrik to figure out what is wrong. I suspect others have been caught in the same situation. Perhaps that was resolved in the week while I was away. I'll be checking after I clear my email backlog. The answer might be in it... There is no intention that xml2rfc be the only way to produce an I-D that is acceptable to the online submission tool. xml2rfc seems to have a higher success rate, and we are working to improve the online submission tool so that all of the various tools have high success rates. Russ At 06:01 PM 6/29/2009, Paul Hoffman wrote: The original thread is about Internet Draft submission, not RFC publication format. The two topics are completely disjoint in the IETF procedures. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, and so must everything else
I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. This author has plenty of problems with xml2rfc. But then, I have plenty of problems with nroff, despite having used it regularly since I used it to write my thesis in the 1970s, and with MS Word despite having used it on and off since Word 6 in the early 1990s. Personally, I can edit XML using emacs and its XML macros without much trouble, since its auto-indent makes it straightforward to figure out what's supposed to match what, and the xml2rfc codes aren't notably harder or easier to remember than nroff directives or Word styles. Just considering the question of what formats are best for authors and readers (not i18n or graphics), I see people talking past each other and getting nowhere. Is it essential that anyone can be fully productive editing I-Ds using teco or vi with no training? Or would it be OK to assume that most people will have access to better tools, so long as it is possible if painful to edit them with a basic text editor? Similarly, does the publication format have to be directly displayable using the native tools found on TOPS-10 or CP/M, or would it be OK to assume that most people will have access to better tools, so long as it's possible to view them in a tty emulator, either directly, or by providing both canonical and rendered versions at the RFC editor FTP or web server? It should be pretty obvious what I think the answers to these questions are, but my answers are clearly not everyone else's. We can't solve the problem until we have rough consensus about what problem we're trying to solve. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Stefan Winter wrote: Plain ASCII makes work on drafts which deal with internationalisation very hard. I have just uploaded a draft with an example second-level domain containing the German small u-Umlaut [U+00FC] as input to an algorithm. Sorry, in fact the draft did of course *not* contain the umlaut. I had to escape it with the [U+00FC]. Writing that impairs the readability and understandability of the example quite a bit since the input on paper is not the same as the actual input. This is, IMHO, severely hindering work. Some more thoughts about this: As long as the IETF want to continue publishing standards in the one single language English, it should restrict the character sets in the texts (and the examples) to ASCII. non-ASCII letters are a royal PITA in so many ways, that they should not be used. Finding a Postscript printer driver that prints umlauts is extremely difficult (I know, I'm German and I can't get PDFs printing properly with Umlauts). Similarly, quite a lot of screen fonts do not contain Umlauts. And although my software is configured to work with iso-8859-1, it is unable to display cyrillic and greek characters. And while I'm German and have keys for umlauts on my keyboard, I have serious difficulties to create other funny characters from the iso-8859-1 character set (like some skandinavian), let alone greek, cyrillic or any symbols from asian languagues. I can not recognize, name or type any of the symbols from asian languages, and I can neither print or display them, nor input them on my keyboard. Which makes it completely impossible to search for them or discuss them. Really, I see no justification why they should be part of an IETF specification, if they're only marginally useful to a (smaller) fraction of the consumers of IETF specs and fairly hostile and unusable to the rest. If the IETF want so allow umlauts, it will have to allow all of Unicode, and that would become close to a catastrophe. 90.0% of the software *I* use is capable of ISO-8859-1, 9.9% is pure-ASCII 0.1% is capable to do more than that (not necessarily full unicode) Actually, most of the common fixed sized fonts seem to contain only ASCII characters (and fixed size fonts happen to be the fonts that I use mostly). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF
Yaakov Stein wrote: ... and don't get me started on LaTeX. I am not sure what problems you had with LaTeX, but as someone who has written thousands of pages using TeX, I can't imagine anything better for professional document preparation. I bought the TeXbook in 1989 and liked it, despite the learning curve. I tried LaTeX in 1992 and junked it. The headerfooters used in the LaTeX book where impossible to create with LaTeX (which I think amounts to cheating), so I dropped back to plain TeX. The problem with most LaTeX documents I came across in 1991-1995 was that they used style files that were extremely hard to find (for someone not using a particular universities infrastructure). The TeX language/syntax takes a little getting used to. Personally I don't like XML at all, and the IETF should NEVER standardize on a particular tool, if any, but only on a very restricted subset of XML tags, if any. (So that tools more mainstream languages can be produced and used). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Martin Rex wrote: Some more thoughts about this: As long as the IETF want to continue publishing standards in the one single language English, it should restrict the character sets in the texts (and the examples) to ASCII. Text? Yes. Examples? Contact info? No. non-ASCII letters are a royal PITA in so many ways, that they should not be used. Disagreed. Finding a Postscript printer driver that prints umlauts is extremely difficult (I know, I'm German and I can't get PDFs printing properly with Umlauts). Similarly, quite a lot of screen fonts do not contain Umlauts. And although my software is configured to work with iso-8859-1, it is unable to display cyrillic and greek characters. I have never had problems printing PDFs with umlauts. And while I'm German and have keys for umlauts on my keyboard, I have serious difficulties to create other funny characters from the iso-8859-1 character set (like some skandinavian), let alone greek, cyrillic or any symbols from asian languagues. That's a totally orthogonal issue. I can not recognize, name or type any of the symbols from asian languages, and I can neither print or display them, nor input them on my keyboard. Which makes it completely impossible to search for them or discuss them. I'm pretty sure that you can display and print at least some of them with a recent browser and operating system. Really, I see no justification why they should be part of an IETF specification, if they're only marginally useful to a (smaller) fraction of the consumers of IETF specs and fairly hostile and unusable to the rest. Non-ASCII characters in I18N examples would be useful to *any* reader. Keep in mind that a consumer of an IETF spec will be able to read English, thus understand the Latin alphabet, and thus be able to understand the difference between, for instance, an e and an é. If the IETF want so allow umlauts, it will have to allow all of Unicode, and that would become close to a catastrophe. I would support allowing all of Unicode for contact information (as long as an ASCII substitute text is available), and a subset for examples. 90.0% of the software *I* use is capable of ISO-8859-1, 9.9% is pure-ASCII 0.1% is capable to do more than that (not necessarily full unicode) Any HTML4 user agent supports Unicode (and no, that doesn't mean it will have fonts to display all of it). Actually, most of the common fixed sized fonts seem to contain only ASCII characters (and fixed size fonts happen to be the fonts that I use mostly). ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF
Martin Rex wrote: ... Personally I don't like XML at all, and the IETF should NEVER standardize on a particular tool, if any, but only on a very restricted subset of XML tags, if any. (So that tools more mainstream languages can be produced and used). ... Could you please elaborate what you mean by restricted subset of XML tags? BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF
Julian Reschke wrote: Martin Rex wrote: ... Personally I don't like XML at all, and the IETF should NEVER standardize on a particular tool, if any, but only on a very restricted subset of XML tags, if any. (So that tools more mainstream languages can be produced and used). ... Could you please elaborate what you mean by restricted subset of XML tags? Something that is sufficiently simple and clear that you can read and understand its semantics while knowing little about XML and that one is able to write a discrete parser in a more mainstream programming languange and NOT use any weird and incompatibly-revved XML-libraries. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF
Martin Rex wrote: Something that is sufficiently simple and clear that you can read and understand its semantics while knowing little about XML and that one is able to write a discrete parser in a more mainstream programming languange and NOT use any weird and incompatibly-revved XML-libraries. So you mean a subset of the XML syntax. Apparently you've had bad experience with XML in the past. I realize that there's a lot of junk out there which calls itself XML parser; but it's certainly not hard to find compliant XML parsers. Just do not use the broken ones. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [xml2rfc] Releasing xml2rfc 1.34pre3?
Marshall Rose wrote: julian, bill - i thought we were waiting on another revision for boilerplate changes? is that imminent? Some changes are upcoming. One was made by the RFC Editor on July, 1st (moving abstract in front of the boiler plate). There was also disagreement on where to move the new 5378 escape clause; I'd need to review this mailing list's archives for details. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Hadriel is right... I quit using xmlmind (never installed on the new machine) because I should not be focusing on formatting nonsense when I should be focusing on generating the correct content. Getting the arcane systax correct always takes me half a day because I am not constantly writing drafts. I am not opposed to tools like xml2rfc in general, but that implementation (even using something like xmlmind with the appropriate filter) represents a giant leap backward to the early 80's world of document creation. As far as I am concerned xml2rfc represents a first step, but we must not stop there. Tony -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hadriel Kaplan Sent: Sunday, July 05, 2009 4:26 PM To: Joel M. Halpern; Iljitsch van Beijnum Cc: IETF Discussion Mailing List Subject: RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. +1 For those who are used to MS-Word, XMLMind is frustrating and truly requires an XML mind. Even simple things like cut/paste are done in a very different (and frankly inconsistent) way, as are references and such. In theory a WYSIWYG word processor shouldn't require an author to know the internal representation and underlying language of the document format. I know a large number if not outright majority of IETF authors do not use MS-Word, so XML2RFC is a fine *option* - but please don't ever *mandate* it and force the rest of us have to write documents in a syntax only a tiny fraction of the planet uses and understands. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 3:16 PM, Doug Ewell wrote: Douglas Otis dotis at mail dash abuse dot org wrote: Reliance upon open source tools ensures the original RFCs and ID can be maintained by others, without confronting unresolvable compatibility issues. Whether a tool is open source or not has nothing to do with how many people know how to use it. Are you talking about maintainability of the documents or of the tools? The concern is about the application accepting document instructions and text and then generating document output. When this application is proprietary, it is prone to change where remedies might become expensive or impossible. The evolution in hardware tends to force the use of different operating systems which may no longer support older applications. IIRC, I did work back in the early 90's that contained Russian written using Word 5. Conversion proved difficult since proprietary fonts were needed. Document recovery then required a fair amount of work to rediscover the structure and character mapping. Trying to get any version of Word to generate plain text outputs consistently always seemed to be a PITA, that varied from version to version, and never seemed worth the effort. It would also be a bad practice to rely upon unstable proprietary formats having limited OS support and significant security issues. Oh, stop. Word 2007 can read and save Word 97 documents. Instead of 10 years, go back another 5 years. When people are required to input Word Document instructions into their Word application, they might become exposed to system security issues as well. The variability of the Word data structures makes identifying security threats fairly difficult, where many missing features seem to be an intended imposition as a means to necessitate use of the vendor's macro language. Inherent security issues alone should disqualify use of proprietary applications. Applications for Windows, which has a 90% to 93% desktop market share, can hardly be said to suffer from limited OS support. When support is almost exclusively Windows, this still represents limited support. It would be sending the wrong message to mandate the use of proprietary operating systems or applications in order to participate in IETF efforts. After all, lax security often found within proprietary operating systems and applications threatens the Internet. And turning off macros is becoming more and more common among Word users; it's even a separate non-default document format under Word 2007. The many automation features fulfilled by TCL and xml2rfc will likely be attempted with the native word processor scripts. The latest Word, if you can afford it, is almost ISO/IEC 29500:2008 Office Open XML compliant. Perhaps Word will be compliant in its 2010 version. :^( I know The Penguin doesn't like the fact that Word is closed-source, but -- like the multiple discussions being lumped under RFC archival format -- we need to separate that issue from questions of whether the app is any good. And if we're talking about an author using Word (or TextPad or roff or whatever) to pre-process a file into an RFC Editor-friendly format, which can then be converted to traditional RFC text or HTML or PDF or something, then isn't the horror of using Word limited to that author? Open source includes more than just Linux, and the exposure of requiring proprietary applications or operating systems would affect nearly all IETF participants that maintain existing documents or generating new ones. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-ospf-hmac-sha (OSPFv2 HMAC-SHA
Cryptographic Authentication) to Proposed Standard The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPFv2 HMAC-SHA Cryptographic Authentication ' draft-ietf-ospf-hmac-sha-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-hmac-sha-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15931rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Message Body Handling in the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has approved the following document: - 'Message Body Handling in the Session Initiation Protocol (SIP) ' draft-ietf-sip-body-handling-06.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Robert Sparks and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-06.txt Technical Summary This document specifies how message bodies should be handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. Working Group Summary There is consensus in the working group to publish this document, and is targeted for Standards Track. Work on this document began in May 2007, and was adopted as a working group item in August 2007. WGLC was issued in June 2008. Document Quality This document specifically addresses an area of SIP that has been an interoperability problem in the past. The SIPit interoperability events have seen many problems in the area of interoperability of MIME handling. This document has been reviews by many participants over the lifetime of the document, by the following members of the WG: - Paul Kyzivat - John Elwell - Francois Audet - Dan Wing - Eric Burger - Dale Worley - Jonathan Rosenberg - Cullen Jennings - Adam Roach Additionally, an extensive APPS area review of the document was been performed by Dave Crocker in an early version of the this document. Personnel Theo Zourzouvillys is the Document Shepherd. Robert Sparks is the Responsible Area Director. RFC Editor Note (applies to version 06 of this document) The XML in figure 2 is invalid due to a missing ''. The Content-Length in the same message is also invalid. Please replace line 230, which is currently: Content-Length: 617 with: Content-Length: 619 Please replace line 250, which is currently: resource-lists xmlns=urn:ietf:params:xml:ns:resource-lists with: resource-lists xmlns=urn:ietf:params:xml:ns:resource-lists ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering' to Informational RFC
The IESG has approved the following document: - 'Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering ' draft-ietf-pce-inter-layer-frwk-10.txt as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-10.txt Technical Summary A network may comprise multiple layers. In some cases it may be valuable to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be used to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). Working Group Summary Good consensus reported (see PROTO writeup in the tracker). Document Quality This document provides an informative framework and as such is not subject to implementation, but rather is useful in the ongoing work of the PCE working group. Personnel JP Vasseur is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note Two references need to be updated: - draft-ietf-pce-brpc has been published as RFC 5441 - draft-ietf-pce-path-key has been published as RFC 5520 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Quick-Start for Datagram Congestion Control Protocol (DCCP)' to Experimental RFC
The IESG has approved the following document: - 'Quick-Start for Datagram Congestion Control Protocol (DCCP) ' draft-ietf-dccp-quickstart-05.txt as an Experimental RFC This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-quickstart-05.txt Technical Summary This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). The document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3 and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). Working Group Summary The document has been produced and reviewed by the DCCP working group and the WG is in agreement to publish this document. A copy of the WG last-call note was also sent to the TSVWG mailing list. Document Quality There are no implementations known of this specification, apart from ns-2 simulations. The key authors of the original Quick-Start RFC 4782 have also reviewed the earlier version of the document, and the document has addressed their comments. Personnel The Document shepherd is Pasi Sarolahti (pasi.sarola...@iki.fi). The Responsible Area Director is Lars Eggert (lars.egg...@nokia.com). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Traceable Anonymous Certificate' to Experimental RFC
The IESG has approved the following document: - 'Traceable Anonymous Certificate ' draft-ietf-pkix-tac-04.txt as an Experimental RFC This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-04.txt Technical Summary This document describes a model for issuing X.509 certificates in which the certificates do not contain the true name of the user, and thus provide some level of anonymity. Traceable Anonymous Certificates (TACs) are issued by a CA that is divided into two parts. One part verifies and records the identity of the user to whom the certificate is issued, and the other issues the certificate to the user but does not know the user's identity. The certificates issued under the TAC model are intended primary for use in web access (and not in applications such as e-mail). The model allows an aggrieved party to request that a TAC CA divulge the identity of a user who has abused the anonymity offered by the certificate. (Details of what constitutes abuse by a user are outside the scope of the document and are established by TAC CA via a Certification Policy.) To void the anonymity offered by the two-arty issuance procedure, both parts of the CA collaborate using a protocol defined in the document. The current version of the model supports only RSA-based security protocols between the two parts of the TAC CA, although the user's certificate may contain a public key for any algorithm. Working Group Summary This document has reached rough WG consensus after considerable debate over the last 18 months. It is targeted at Experimental status. This work did not attract much interest from most WG members initially. It addresses a PKI niche, which some WG members didn't think would ever be of commercial interest. The document authors were Korean and they had considerable trouble expressing their ideas in writing, and in a suitable style for an IETF standard. Steve Kent, my co-chair, agreed to become a co-author and he re-wrote the document and has coordinated subsequent revisions. Two WG members provided extensive reviews of the I-D, which resulted in a number of changes to address technical details. The version that entered WGLC triggered comments from a few WG members. Changes were made to address several of these comments, but a suggestion to make a substantial design change was rejected. Two WG members raised concerns whether the split-signature technology employed here adds enough security to merit the increased complexity. However, the principle authors work for KISA, the Korean Information Security Agency that accredits CAs in that country. Their judgment that this is a reasonable tradeoff is enough to merit progression as experimental document. The real proof of the document's value will be decided based on adoption by CAs, something the KISA authors say will happen (at least in their country). Document Quality There are no know implementations at this time, which is not surprising for a document targeted at Experimental status. However, the KISA staff who are the principle authors have indicated that they anticipate at least one commercial TAC CA (in South Korea) will be forthcoming after an RFC is published. An organization that chooses to implement the model described here will be a CA service provider, not a product vendor per se. RFC Editor Note This document is being forwarded for publication assuming that the proposed update to the TLP will be completed by the IETF Trust prior to completion of the RFC publication process. If that process does not terminate successfully, please make the following substitution in Appendix A, replacing RFC with the number assigned to this RFC: OLD DEFINITIONS IMPLICIT TAGS ::= NEW DEFINITIONS IMPLICIT TAGS ::= -- -- Copyright (c) 2009 IETF Trust and the persons identified as -- authors of the code. All rights reserved. -- -- Redistribution and use in source and binary forms, with or without -- modification, are permitted provided that the following conditions -- are met: -- -- - Redistributions of source code must retain the above copyright -- notice, this list of conditions and the following disclaimer. -- -- - Redistributions in binary form must reproduce the above copyright -- notice, this list of conditions and the following disclaimer in -- the documentation and/or other materials provided with the -- distribution. -- -- - Neither the name of Internet Society, IETF or IETF Trust, nor the -- names of specific contributors, may be used to endorse or promote -- products derived from this software without specific prior -- written permission. -- -- -- -- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -- 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -- LIMITED TO,
Document Action: 'Comcast's ISP Experiences In a P4P Technical Trial' to Informational RFC
The IESG has approved the following document: - 'Comcast's ISP Experiences In a P4P Technical Trial ' draft-livingood-woundy-p4p-experiences-10.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-livingood-woundy-p4p-experiences-10.txt Technical Summary This document discusses what has been learned about ALTO-style traffic optimization in trials run by ComCast and Pando. The discussion is informative and should inform discussions about what realistic outcomes can be expected with use of similar technology. Working Group Summary This is an individual submission. Document Quality The document has had sufficient review. Personnel Lisa Dusseault is the responsible area director. RFC Editor Note Please put the following content in the Security Considerations: This document does not propose any kind of protocol, practice or standard. The experiment did show that an ISP can improve performance without exposing fine-grained details about network structure, which might otherwise be a security concern (see Section 3.1 (P4P Fine Grain) and Section 3.2 (P4P Coarse Grain)). Section 6 (Next Steps) mentions that the opt-in architecture allows P2P users to maintain privacy. Other security aspects were not considered in the experiment, which focused on performance measurements. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DNS Proxy Implementation Guidelines' to BCP
The IESG has approved the following document: - 'DNS Proxy Implementation Guidelines ' draft-ietf-dnsext-dnsproxy-06.txt as a BCP This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-06.txt Technical Summary This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary The consensus for this document is real strong. Document Quality This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
75th IETF - Final Agenda
The Final agenda is now available at: http://www.ietf.org/meetings/75/ Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
