Abfab@IETF80
Hi, At the risk of causing my mail box to be filled with flames... I want to draw your attention to the fact that the first of the 2 Abfab sessions (Monday 1510-1610 Abfab I, Karlin I) will be dedicated to the overall architecture, example use cases and current implementation status. So if you want to find out what this Abfab stuff is about this may serve as a gentle introduction... Klaas (Abfab co-chair) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ 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: draft-housley-two-maturity-levels
As far as I can tell, your proposal does not match the meaning we use for Historic. More importantly, there does not seem to be a problem that needs to be addressed in this area. Most importantly, if there is a problem, it should in my opinion be addressed separately from the topic of this draft. Please do not conflate the two. Yours, Joel M. Halpern On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote: Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
24.03.2011 17:42, Joel M. Halpern wrote: As far as I can tell, your proposal does not match the meaning we use for Historic. More importantly, there does not seem to be a problem that needs to be addressed in this area. Most importantly, if there is a problem, it should in my opinion be addressed separately from the topic of this draft. Please do not conflate the two. While it is not directly related to the draft's topic, it it just an attempt since this draft is very likely to become published unlike the separate proposal on this topic. Mykyta Yours, Joel M. Halpern On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote: Russ, all, Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Therefore, I propose the following text: 6. Procedures for Reclassification of Standards Track RFCs as Historic Documents Under some circumstances Standards Track RFCs may be reclassified to Historic document (i. e. its initial status may be changed to Historic). RFC 2026 [1], as well as its predecessors, contains some words about the Historic RFCs, but it failes to define the procedures for reclassification of RFCs to Historic status. Such situation, of course, causes misunderstandings of the members of the community. This document removes this uncertainty; it defines the circumstances under what the Standards Track RFC should be moved to Historic status and describes the procedures for such action. The Standards Track RFC, either Proposed Standard or Internet Standard, should be considered to be appropriate for reclassification as Historic document if (a) there is another document that replaces it or (b) it described the protocol or other technology that got out-of-use. In the case mentioned as (a) above the superseding document should just have the notice of the necessity of reclassification of its predecessor to Historic. However such action is not obligatory. In the case mentioned as (b) above the procedure is as follows. If the individual or a group of individuals (e. g. IETF working group) assume that the protocol or other technology defined in the Standards Track RFC is now out-of-use and is very unlikely to become widely used in the future, they SHALL apply to IESG to request the reclassification of such document to Historic. IESG SHALL then issue the IETF-wide Last Call on this action, not shorter than 2 weeks, in order to determine whether there is the community consensus on reclassification. If Last Call did not reveal community objection to this action, this document SHALL be reclassified to Historic. During the sunset period, set by this document, Draft Standards SHALL be reclassified to Historic using the procedure as defined above. ... and renumber the following sections. What do you think about this proposal? Mykyta Yevstifeyev 14.03.2011 1:32, Russ Housley wrote: There have been conflicting suggestions about the best way forward. We have constructed an updated proposal. It has been posted as draft-housley-two-maturity-levels-04. Russ ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote: On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
I can't escape the feeling that this discussion of using markup language editing to produce RFCs, is a bit upside down. I'm much more concerned with draft writers having to deal with markup syntax than I am about drafters trying to put a page break in a sensible location, or format their text in a readable fashion. The latter is not a problem that consumes a lot of energy, neither do I believe that drafters concern with readability is a matter that causes the RFC production center a lot of headache. So why is this a matter of concern? I honestly think people waste a lot more time trying to figure out how to properly form correct markup syntax, than they do with format tweaking. My experience has been the exact opposite. Markup syntax is a known quantity that is easily accomodated, especially if you use a markup-aware editor. The editor I use closes elements automatically, provides constant syntax checks, and lets me toggle sections of the document in and out of view. It's been a very long time since I've given any real thought to the supposed difficulties of dealing with markup syntax. But page breaks... I have on more occasions than I care to recall spent a swacking big chunk of time adjusting them. Fix one widow, an orphan appears somewhere else. And yes, I realize this is not really necessary for I-Ds, but when the breaks are really bad I just can't help but try and fix them. In my ideal world, where XML would work at its best, drafters would concentrate on writing text in a fashion that could be captured into XML (or any functional markup language), making XML the output of the editing process rather than the input. Brian Reid once came up with a nice term for what results when this goal is pursued to it's logical conclusion: What You Get is What You Deserve. That way it would not hurt the drafters if the XML syntax was extended to capture both content and format, making it a complete input to the rendering process. Given the rather primitive structure of RFCs, writing such editor seem not to be such a grim task. I'm even tempted to provide one in the next major version of NroffEdit, where you could choose nroff and/or XML as markup, but never bother with it when writing your draft. The task may not be grim, but the end results of such exercises - and there have been a lot of them - usually are. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Ned, On 11-03-24 9:48 PM, Ned Freed ned.fr...@mrochek.com wrote: I can't escape the feeling that this discussion of using markup language editing to produce RFCs, is a bit upside down. I'm much more concerned with draft writers having to deal with markup syntax than I am about drafters trying to put a page break in a sensible location, or format their text in a readable fashion. The latter is not a problem that consumes a lot of energy, neither do I believe that drafters concern with readability is a matter that causes the RFC production center a lot of headache. So why is this a matter of concern? I honestly think people waste a lot more time trying to figure out how to properly form correct markup syntax, than they do with format tweaking. My experience has been the exact opposite. Markup syntax is a known quantity that is easily accomodated, especially if you use a markup-aware editor. The editor I use closes elements automatically, provides constant syntax checks, and lets me toggle sections of the document in and out of view. It's been a very long time since I've given any real thought to the supposed difficulties of dealing with markup syntax. But you are probably pretty experienced user and you probably spent some time setting up your environment to get where you are. I believe having to deal with markup syntax poses a significant barrier to those not as experienced as you. But page breaks... I have on more occasions than I care to recall spent a swacking big chunk of time adjusting them. Fix one widow, an orphan appears somewhere else. And yes, I realize this is not really necessary for I-Ds, but when the breaks are really bad I just can't help but try and fix them. It's been a very long time since I experienced any problem with formatting. :) That was in the old days when I used a separate Nroff compiler. Using NroffEdit's side by side view of source and text has completely removed that issue for me. And I think that is true also for an inexperienced user. In my ideal world, where XML would work at its best, drafters would concentrate on writing text in a fashion that could be captured into XML (or any functional markup language), making XML the output of the editing process rather than the input. Brian Reid once came up with a nice term for what results when this goal is pursued to it's logical conclusion: What You Get is What You Deserve. Great one And so true. That way it would not hurt the drafters if the XML syntax was extended to capture both content and format, making it a complete input to the rendering process. Given the rather primitive structure of RFCs, writing such editor seem not to be such a grim task. I'm even tempted to provide one in the next major version of NroffEdit, where you could choose nroff and/or XML as markup, but never bother with it when writing your draft. The task may not be grim, but the end results of such exercises - and there have been a lot of them - usually are. I believe you are right, looking in the mirror. But time changes. I think this is an area where open source development and open source libraries really has provided a revolution. If we start with creating the specifications that would allow such tool to be created, then you don't need a huge software organization and kazillions of dollar any more to piece together something that actually could be really useful.. I know I'm an idealist.. I still believe in simplicity. /Stefan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
But you are probably pretty experienced user and you probably spent some time setting up your environment to get where you are. The answer is no to both. When I first started using xml2rfc I don't think I had written a single line of XML. As for setting up the editing environment, I installed a new version of BBEdit, done. The hard part was actually getting xml2rfc up and running. This was back when I was using Mac OS 9, and getting that combination working was a bit of a pain. (I think my directions on how to do it eventually ended up in the readme.) Since then I've done much more advanced work with XML involving schemata, Relax, stylesheets, and so on and so forth. BBEdit is in no way adequate for that stuff, and truth be told I'm not happy with any of the more powerful tools I've tried. (I'm currently limping along with Exchanger, but it hasn't been updated in a long time.) I believe having to deal with markup syntax poses a significant barrier to those not as experienced as you. I realize that's your belief. But after having watched multiple technical neophytes learn how to produce better results with TeX than I usually can - and when it comes to markup, the rules for XML are the essence of simplicity compared to TeX - it is not a belief I share. ... I believe you are right, looking in the mirror. But time changes. I think this is an area where open source development and open source libraries really has provided a revolution. If we start with creating the specifications that would allow such tool to be created, then you don't need a huge software organization and kazillions of dollar any more to piece together something that actually could be really useful.. I know I'm an idealist.. I still believe in simplicity. As do I, but what I'm not seeing is an approach that leverages all the stuff you mention to actually produce a different outcome. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
Agreed. On Mar 24, 2011, at 12:13 PM, Bob Hinden wrote: On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote: On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote: Another proposal as for your document. So, it fails to mention what are the procedures for reclassification of Standards Track RFCs to Historic. Generally, the document tries to limit itself to discussion of what it changes. There are no changes proposed for moving to Historic. (The question of Historic has not been part of the many discussions about streamlining the standards labeling.) Hence that issue is out of scope for the document. +1 Bob ___ 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: Automatically updated Table of Contents with Nroff
I believe having to deal with markup syntax poses a significant barrier to those not as experienced as you. From long experience, I can assure you that whatever you are used to seems obvious and natural, and whatever you aren't seems strange and difficult. I think nroff is swell, having been using it since about 1973, but on the rare occasions I show it to someone, their reaction is about what I'd get if they looked into my kitchen and saw a bunch of goat legs, a pile of coal, and a bellows. Lots of people use XML editors like bbedit and xxe. They're not my favorite, but they seem quite popular. Some of us weenies hand-edit XML, which is not noticably more painful than hand-editing nroff or any other text based markup language. (It's a lot easier than hand-editing RTF, though.) XML is clearly the future. The tools are way better, like saxon and xsltproc which use templates to turn XML into web pages or whatever else you want. (And no, running nroff source through troff isn't the same thing.) If you want to use nroff, that's fine, but it's really a dead end. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 41 messages in the last 7 days. script run at: Fri Mar 25 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 7.32% |3 | 7.21% |22774 | ste...@aaa-sec.com 7.32% |3 | 7.09% |22391 | evniki...@gmail.com 7.32% |3 | 6.59% |20813 | s...@resistor.net 4.88% |2 | 5.99% |18930 | ves...@tana.it 4.88% |2 | 5.77% |18226 | sambaini...@gmail.com 4.88% |2 | 5.04% |15913 | dean.wil...@softarmor.com 4.88% |2 | 4.08% |12888 | ned+i...@mauve.mrochek.com 2.44% |1 | 6.36% |20076 | henry.sinnre...@gmail.com 4.88% |2 | 3.79% |11972 | bob.hin...@gmail.com 2.44% |1 | 5.50% |17353 | rich...@shockey.us 2.44% |1 | 4.87% |15394 | hannes.tschofe...@nsn.com 2.44% |1 | 3.43% |10826 | hal...@gmail.com 2.44% |1 | 3.04% | 9596 | dburn...@voxeo.com 2.44% |1 | 2.61% | 8250 | brian.e.carpen...@gmail.com 2.44% |1 | 2.44% | 7696 | t...@att.com 2.44% |1 | 2.41% | 7615 | j...@joelhalpern.com 2.44% |1 | 2.36% | 7441 | nar...@us.ibm.com 2.44% |1 | 2.34% | 7382 | paul.hoff...@vpnc.org 2.44% |1 | 1.96% | 6205 | john-i...@jck.com 2.44% |1 | 1.94% | 6127 | mohamed.boucad...@orange-ftgroup.com 2.44% |1 | 1.81% | 5717 | tglas...@earthlink.net 2.44% |1 | 1.79% | 5646 | eburge...@standardstrack.com 2.44% |1 | 1.55% | 4890 | joe...@bogus.com 2.44% |1 | 1.55% | 4887 | d...@dcrocker.net 2.44% |1 | 1.48% | 4669 | emiur...@gmail.com 2.44% |1 | 1.47% | 4639 | f...@isoc.org 2.44% |1 | 1.45% | 4569 | kl...@cisco.com 2.44% |1 | 1.42% | 4498 | jo...@iecc.com 2.44% |1 | 1.41% | 4453 | hannes.tschofe...@gmx.net 2.44% |1 | 1.25% | 3953 | julian.resc...@gmx.de +--++--+ 100.00% | 41 |100.00% | 315789 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6196 on Moving mailserver: URI Scheme to Historic
A new Request for Comments is now available in online RFC libraries. RFC 6196 Title: Moving mailserver: URI Scheme to Historic Author: A. Melnikov Status: Standards Track Stream: IETF Date: March 2011 Mailbox:alexey.melni...@isode.com Pages: 3 Characters: 5679 Updates:RFC1738 I-D Tag:draft-melnikov-mailserver-uri-to-historic-00.txt URL:http://www.rfc-editor.org/rfc/rfc6196.txt This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
