Re: Towards consensus on document format
Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: HTML is already too complex and unstable that there is no hope that UNSTABLE? Is it still version 1.0? The current version is 4.01, and it has been stable since 1999. The next version, 5, is approaching Last Call, and is unlikely to break anything that is actually in use. So your definition of stable is that there are no post-1.0 versions? Even compatible ones? Just asking... Tools does not support restricted profile very well, as was demonstrated by a circled 'R' character in a claimed-to-be-pure-ASCII PDF. So Microsoft Word inserted a registered-trademark symbol into an *internal properties field* of a PDF file whose *contents* were claimed to be pure ASCII, and now it is claimed that this demonstrates not only that the contents of a PDF file cannot be plain ASCII, but also that HTML is too unstable for a reduced-feature profile to be successful? For an Engineering Task Force, this group sure does surprise me sometimes with its logical reasoning. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Doug Ewell writes: So Microsoft Word inserted a registered-trademark symbol into an *internal properties field* of a PDF file whose *contents* were claimed to be pure ASCII, and now it is claimed that this demonstrates not only that the contents of a PDF file cannot be plain ASCII, but also that HTML is too unstable for a reduced-feature profile to be successful? For an Engineering Task Force, this group sure does surprise me sometimes with its logical reasoning No, Ohta-san surprises you. FYI this is an invariant: Ohta-san continues to surprise you, even after you grow used to him. (At this point I would like to remark that I am sure Ohta-san has good and valuable insights, and that I wish they were easier to notice.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Brian E Carpenter brian dot e dot carpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 16.03.2010 14:14, Doug Ewell wrote: Brian E Carpenter brian dot e dot carpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. Indeed. Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 15.03.2010 22:34, Julian Reschke wrote: On 15.03.2010 22:19, Martin Rex wrote: ... It needs a painful lot of work to make free-floating formating not come out with poor results. When I do the above, an ascii arts with 3 lines of text and a box around is broken over from page8-page9 for http://greenbytes.de/tech/webdav/rfc2616.html ... Yes. (And thanks for retrying). What you are observing is missing support for CSS3 paged media hints in most browsers. It would be great if the UAs would get better on that. (PrinceXML (http://www.princexml.com/) is a great program that gets this right). ... And, as it seems, IE8 and Opera... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 3/16/2010 6:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. There were a few different proposals. Some had support. Others probably didn't. What was missing was a directed exercise at trying to reach consensus. As is usual for anything in front of the full IETF, a free-for-all exchange meets with various objections and there is no follow-through to try to resolve things. Any momentum that might have built then dissipates. For spontaneous efforts, like these, it would be helpful to get a facilitator appointed to serve something similar to the role of working group chair, to try to resolve differences and assess consensus. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I agree, there did seem to be lots of support for it, including my own. But I don't think anyone really wanted to stand up and act as the WG Chair and declare concensus. After all, this is a basic infrastructure item that spans the entire IETF+IRTF+IAB space. Who is in charge of managing that entire community? It seems like there should be a serious presentation of the topic at one of the upcoming plenaries, with subsequent discussion, with the aim at coming to a concensus. Tony Hansen t...@att.com On 3/16/2010 9:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I would suggest that this topic is something the RFC Series Editor (transitional or otherwise) would/should/could consider. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 16 Mar 2010, Dave CROCKER wrote: On 3/16/2010 6:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. There were a few different proposals. Some had support. Others probably didn't. What was missing was a directed exercise at trying to reach consensus. As is usual for anything in front of the full IETF, a free-for-all exchange meets with various objections and there is no follow-through to try to resolve things. Any momentum that might have built then dissipates. For spontaneous efforts, like these, it would be helpful to get a facilitator appointed to serve something similar to the role of working group chair, to try to resolve differences and assess consensus. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: Towards consensus on document format
Since there is nobody suggesting a modification of the document format from 7 bit plaintext to UTF8 and since further it is clear that this would satisfy neither camp, I fail to see the relevance for including it. Expressing surprise that such an option has not been considered is, well 'interesting'. On Mon, Mar 15, 2010 at 12:42 PM, Doug Ewell d...@ewellic.org wrote: Phillip Hallam-Baker hallam at gmail dot com wrote: 9) Ability to code names properly 10) Ability to write an intelligible document on internationalization issues ... 8, 9, 10) Only supported by HTML. I continue to be puzzled by statements like this. A plain-text file encoded in UTF-8 can contain any Unicode character that an HTML document can contain. Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I have submitted HTML into that Web form. And then what happened to it...? That is the real complaint here. Most of us are now writing documents in a process that uses XML for authoring and HTML for reviewing. Then the result is taken and reduced to 1960s teletype. On Mon, Mar 15, 2010 at 12:22 PM, Julian Reschke julian.resc...@gmx.de wrote: On 15.03.2010 17:16, todd glassey wrote: On 3/15/2010 9:07 AM, Julian Reschke wrote: On 15.03.2010 17:00, todd glassey wrote: ... Sorry - but the IETF should have moved into Web Based automated document submission years ago. ... It did. Best regards, Julian Julian - if this was done properly there would be no need for an Editor per se... so no they did not. They automated very minor parts of the process but mandated the ASCII format for the main filings. Well, you can submit your documents through a web form; this has been available for quite some time. This is orthogonal to the actual publication process. ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Mon, Mar 15, 2010 at 11:53 AM, Melinda Shore melinda.sh...@gmail.com wrote: Phillip Hallam-Baker wrote: What I find rather puzzling here is that most of the defenders of the status quo are saying 'document format is really no big deal, why make a fuss'. ?? I haven't seen anybody argue that, actually, and it would be odd if they did. I see numerous statements of that form in the thread. I am in class E. I find being required to edit documents in teleprinter format to be very insulting to me personally. That's another odd argument, although it does tend to support that this is a matter of individual sensibilities. As nearly as I can tell, people who like to work lower in the stack tend to prefer certain kinds of formats and people who work higher in the stack tend to prefer others. People who don't like strongly-typed languages probably aren't going to be enthusiastic about strongly-typed document formats. It could come down to tastes and possibly to comfort level with various tools, and it seems unlikely to me that haranguing people about it will change their personal relationships with the various technologies. And people wonder why the applications people have mostly deserted to W3C and/or OASIS. I don't see the relevance of strong typing. When I worked on routing level issues I was using formal methods to specify them. It does not get any more strongly typed than Z/VDM. One of the reasons I prefer using XML for document preparation is that it allows me to use automated tools to assemble / validate individual components of the spec. For example when I was working on SAML 1.0 I had scripts that generated the schema and documentation from a source file and then validated the examples against the schema. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Periodic debates
And so we would have a WiKi in HTML to explain why the document format is in teletype format. On Mon, Mar 15, 2010 at 12:49 PM, Dave CROCKER d...@dcrocker.net wrote: On 3/11/2010 7:32 AM, Donald Eastlake wrote: Periodically, there are flame wars on the IETF mailing list that the IETF should / shouldn't... Mayhap we should create a FAQ wiki that captures the essence of these debates, so that we can simply cite the relevant entry when the topic arises, and revise the entry when (if) someone offers a new datum to the debate? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
+1 Since nobody was using teleprinters 500 years ago the introduction of them here as a point of difference is ridiculous. And the idea that HTML is any less stable than the hacks people have developed to make non-ASCII characters work in ASCII is totally absurd. We can reasonably expect that within the next ten, twenty years, handwriting recognition will render such hacks obsolete and the memory of them will be as obscure as Morse code is today. I don't think there is any real likelihood we will entirely loose the ability to decipher such hacks, any more than it is likely that all traces of Morse will ever disappear. But that knowledge is going to become increasingly obscure and ambiguous. There is no way that I am going to take a document on 'internationalization' seriously if it is printed in an idiotic format requiring recourse to obscure transcoding hacks to decipher it when both the original source document preparation format (XML2RFC) and my screen are capable of displaying the actual character. Absolutely the only reason that the information is not present is that some people have decided that their opinions are s damn important that they are going to maliciously and spitefully create shit-work for me. On Mon, Mar 15, 2010 at 5:20 PM, Julian Reschke julian.resc...@gmx.de wrote: On 15.03.2010 22:08, Masataka Ohta wrote: Phillip Hallam-Baker wrote: Before you answer that, here is a list of consensus requirements on the document format: The fundamental consensus requirement is that the document format MUST be widely (and internationally) legible. The internationalization requirement automatically excludes non-ASCII characters. How so? Pure ASCII HTML may (or may not) be widely legible. However, 2) Readily supported by a wide range of authoring tools 3) Conformance can be checked using automatic tools 4) Open specification, stable, non proprietary HTML is already too complex and unstable that there is no hope that UNSTABLE? some IETF-specific profiling can be widely and stably supported. Disagreed. 5) Reversible, able to recover editing format from publication format I do not believe reversibility is required as long as the source format is preserved. It would be nice, though. Reversibility does not help if an editor can not recognize (nor input) some character, which also requires pure ASCII. Please elaborate. 6) Longeivity, guarantee of being able to interpret them in 1000 years Then, we should use a format available at least 500 years ago. Were you using HTML 500 years ago? Very helpful. Best regards, Julian -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
No, your claim was a canard because it is a test that your preferred document format cannot meet. I do not need to have the evidence of 500 years of experience of using HTML to be able to demonstrate that HTML will be readable in 1000 years time. The difficulty of deciphering HTML is remarkably lower than the difficulty of deciphering Linear B (3500 years old), Egyptian hieroglyphs (last used 1600 years ago) or Mayan hieroglyphs (last used 400 years ago). Many people have successfully decoded HTML without any access to the standard whatsoever. The idea that we shoudld worry about lack of ability to decipher it is totally absurd. The value of information encoded in HTML is simply too great for that ever to happen as long as civilization lasts. I really don't think it is worth while arguing that the RFC series is of such utmost importance that we need worry about ability to maintain it any longer. On Mon, Mar 15, 2010 at 7:43 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Since nobody was using teleprinters 500 years ago the introduction of them here as a point of difference is ridiculous. I can't see your point. Are you begging our pardon and withdraw your stupid statement of being able to interpret them in 1000 years time? Or? Masataka Ohta -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the IAB technical advice on the RPKI
There is a big difference in real engineering (i.e. outside a university) between a solution that only addresses part of a problem and one that is 'useless'. In this case it is much more important to restrict the application of cryptography to problems that it solves well than to attempt to solve every problem. In observed attacks and in simulations, the IP-AS number attack is much more significant than the routing layer attack in most circumstances. The IP-AS attack is global, the effects of the routing layer attack are local. There are many security concerns that BGP security could address. The only concerns for which a BGP security solution is essential is to prevent Denial of Service attacks and to prevent hijacking of IPv4 space after exhaustion is reached. I believe that the most likely scenario in which BGP security is actually deployed is that the IPv4 space runs out and we then see a huge increase in address block theft and bogon injection by spammers and other malicious actors. I have deliberately crafted a solution that can be applied in a 'save your ass' mode. The routing level attack will remain, but that is only an issue for AS networks that are not directly connected. Networks that are directly connected are not going to be fooled by bogus routes, particular not by routes that are several hops removed. While that may seem a somewhat callous observation 'ok, so huge chunks of the net can fail', the point is that we can avoid some of the more painful consequences of critical infrastructure that relies on IP connectivity collapsing through some fairly simple measures. We can also avoid deadlock situations where the net falls down and we can't bring it back because the routing tables are totally contaminated. In practice though, the consequences of routing manipulation are manageable. Worst case we can revert to the routing tables that worked an hour ago. or a day ago and get to 95% normalcy. On Mon, Mar 15, 2010 at 7:24 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: As was discussed already in this ML, RPKI is useless. Even if an AS owning an address block is securely known, it does not secure routing to the address block through other ASes. Masataka Ohta -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Well, I will just point out that the whole discussion was kicked off by a gratuitous defense of the existing format. As for the rejection of Paul's proposal, it is entirely logical to reject a change that fails to go far enough. And your ability to block change in the past is hardly a justification for blocking any changes in the future. If you decide to put it in those terms then the format discussion becomes a debate on the question of whether the IETF is capable of any sort of reform, any sort of growth. If the answer is that it is not then it is a rather sad indictment of the institution. As for 'tendentious', there is nothing particularly 'plain' about being required to have an exact number of lines per page, a number of lines chosen for compatibility with 1960s era dot matrix printers. Teletype format seemed to be considerably less confrontational than the term I have been using in conversation for many years now. On Mon, Mar 15, 2010 at 9:18 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2010-03-16 05:42, Doug Ewell wrote: ... Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. This was originally in RFC 2223 and its predecessors back to RFC825. Now it's in http://www.rfc-editor.org/rfc-style-guide/rfc-style Since we failed to get consensus even on the minor step proposed by http://tools.ietf.org/id/draft-hoffman-utf8-rfcs, I really don't see this conversation converging on a radical change. Also, PHB's list of options is tendentious (by referring contemptuously to teleprinter format) and ambiguous (since there is no such thing as the HTML format for RFCs). As an archival format, I am still very happy with ASCII. Guaranteed layout, trivially searchable. The tools team HTML markup is nice, but redundant as far as archiving goes. Brian (who will once again regret having risen to the bait) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I developed tools to convert RFC from/to mediawiki pages. As long as RFC 3935 obliges to use English ASCII, the simplest English ASCII format is the best as it permits easy format conversion. The only real problem I meet is the impossibility to use circles in figures. jfc 2010/3/16 Julian Reschke julian.resc...@gmx.de On 16.03.2010 14:14, Doug Ewell wrote: Brian E Carpenter brian dot e dot carrpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. Indeed. Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. Best regards, Julian ___ 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: Towards consensus on document format
On Tue, Mar 16, 2010 at 9:22 AM, Julian Reschke julian.resc...@gmx.de wrote: On 16.03.2010 14:14, Doug Ewell wrote: Brian E Carpenter brian dot e dot carpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. Indeed. Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. Some people are more equal than others. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Mar 16, 2010, at 10:48 AM, Tony Hansen wrote: I agree, there did seem to be lots of support for it, including my own. But I don't think anyone really wanted to stand up and act as the WG Chair and declare concensus. After all, this is a basic infrastructure item that spans the entire IETF+IRTF+IAB space. Who is in charge of managing that entire community? I believe that the IETF Chair calls consensus on general IETF matters, when necessary. Regards Marshall It seems like there should be a serious presentation of the topic at one of the upcoming plenaries, with subsequent discussion, with the aim at coming to a concensus. Tony Hansen t...@att.com On 3/16/2010 9:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. ___ 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: Towards consensus on document format
Circles are not impossible, just a pain: http://tools.ietf.org/html/rfc5491#section-5.2.7 Likewise for normal distributions: http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-04 On Mar 16, 2010, at 2:57 PM, JFC Morfin wrote: I developed tools to convert RFC from/to mediawiki pages. As long as RFC 3935 obliges to use English ASCII, the simplest English ASCII format is the best as it permits easy format conversion. The only real problem I meet is the impossibility to use circles in figures. jfc 2010/3/16 Julian Reschke julian.resc...@gmx.de On 16.03.2010 14:14, Doug Ewell wrote: Brian E Carpenter brian dot e dot carrpenter at gmail dot com wrote: Note that I am not arguing in favor of plain text as the IETF standard. I just want to keep this part of the discussion real. There is no requirement anywhere that plain-text files may contain only ASCII characters. That requirement is explicit for RFCs. It is explicit for RFCs, but not for plain-text files in general. IETF could theoretically change the RFC requirement, although you are correct that given the non-acceptance of draft-hoffman-utf8-rfcs, it seems unlikely. The topic did come up again on the list, with the usual conflation of ASCII and plain text. Indeed. Speaking of which: did we ever *measure* the acceptance of draft- hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. Best regards, Julian ___ 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: Towards consensus on document format
At 07:48 16-03-10, Tony Hansen wrote: I agree, there did seem to be lots of support for it, including my own. But I don't think anyone really wanted to stand up and act as the WG Chair and declare concensus. After all, this is a basic infrastructure item that spans the entire IETF+IRTF+IAB space. Who is in charge of managing that entire community? It falls under the IAB. If the RFC Style Guide is a policy matter, the IAB approves of the change. If it is within the responsibilities of the RFC Series Editor (Transitional), he could work on this matter as it is the main preoccupation of the IETF Community this month. I have some unfounded theories about how this may be played. If the populace brings this up to the IESG, the latter will redirect the request to the IAB. The IAB will set up a committee to work with the RFC Series Editor on the matter. Decision by committee has its advantages as nobody gets to take the fall when things go wrong. It also offers some protection for the RFC Series Editor. That is a necessary as the latter is part of a rare species. One might want to consider whether the question of document format is so critical that it has to be addressed immediately. The resolution will likely take over a year but let's not get into such details. To sum up, this is a debate where each camp tries to convert the other. Like all the religious wars of the past, logic is not the decisive tool. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 3/16/10 6:22 AM, Julian Reschke wrote: Speaking of which: did we ever *measure* the acceptance of draft-hoffman-utf8-rfcs? As far as I recall, there was lots of support for it. The draft expired at rev 5, but can be found at: http://tools.ietf.org/html/draft-hoffman-utf8-rfcs -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 13 mrt 2010, at 21:54, Phillip Hallam-Baker wrote: So in the hope of finding consensus here, lets see what people's position actually is A) The format issue does not matter B) The format issue matters a little to me and I prefer the teleprinter format C) The format issue matters a lot to me and it MUST be teleprinter format D) The format issue matters a little to me and I prefer the HTML format E) The format issue matters a lot to me and it MUST be HTML format Haven't read the discussion until now (will do that tomorrow) but let me add F and cast the first vote in favor of it: F) HTML that reverts back to usable ASCII (although I'm willing to live without headers/footers and the whitespace may look a bit different as long as it's self-consistent) when everything between and is removed from the file and a very limited set of *; sequences has been searched and replaced. No images because those can't be viewed without non-trivial tools and they are extremely hard to modify from the published version. I am in class E. I find being required to edit documents in teleprinter format to be very insulting to me personally. I take a great pride in my work and I do not like being forced to present it in a format where the principle justification for it appears to be 'because we can force you to do it our way'. replace document format with xml2rfc xml format and I'm with you 100%. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Doug Ewell wrote: Tools does not support restricted profile very well, as was demonstrated by a circled 'R' character in a claimed-to-be-pure-ASCII PDF. FYI, your claim was: : Here is an example of PDF-A that uses nothing but ASCII characters: a PDF file whose *contents* were claimed to be pure ASCII See above. and now it is claimed that this demonstrates not only that the contents of a PDF file cannot be plain ASCII, but also that HTML is too unstable for a reduced-feature profile to be successful? Are you saying your PDF-A file is good but your definition of PDF-A is bad? But, broken definition is worse than broken tools, which, even more strongly, means we must not use profiled subset. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Mon, Mar 15, 2010 at 5:18 PM, Phillip Hallam-Baker hal...@gmail.com wrote: +1 Since nobody was using teleprinters 500 years ago the introduction of them here as a point of difference is ridiculous. And the idea that HTML is any less stable than the hacks people have developed to make non-ASCII characters work in ASCII is totally absurd. We can reasonably expect that within the next ten, twenty years, handwriting recognition will render such hacks obsolete and the memory of them will be as obscure as Morse code is today. I'd love to see you trapped in a basement after an earthquake with only a stick trying to remember how to tap S-O-S. Hard to believe but Morse is still in use and required for certain classes of radio operators. Cheers Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Mon, Mar 15, 2010 at 1:05 PM, Phillip Hallam-Baker hal...@gmail.com wrote: I have submitted HTML into that Web form. And then what happened to it...? That is the real complaint here. Most of us are now writing documents in a process that uses XML for authoring and HTML for reviewing. Then the result is taken and reduced to 1960s teletype. And the most fascinating thing, you can still read the document if you have one !!! Cheers Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I'll say that I'm in category c: the format issue matters a lot to me and I prefer the status quo. Changing the format issue is difficult, people who want to change it routinely ignore some of the issues, and neither side participates in a constructive discussion. The status quo is acceptable and we could do far worse. Phil I cannot imagine being insulted by a document format, but I feel very uncomfortable with a change being lead by a group of people that feel that strongly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Mar 16, 2010, at 5:59 PM, Jorge Amodio wrote: On Mon, Mar 15, 2010 at 5:18 PM, Phillip Hallam-Baker hal...@gmail.com wrote: +1 Since nobody was using teleprinters 500 years ago the introduction of them here as a point of difference is ridiculous. And the idea that HTML is any less stable than the hacks people have developed to make non-ASCII characters work in ASCII is totally absurd. We can reasonably expect that within the next ten, twenty years, handwriting recognition will render such hacks obsolete and the memory of them will be as obscure as Morse code is today. I'd love to see you trapped in a basement after an earthquake with only a stick trying to remember how to tap S-O-S. That's easy. Three shorts and three longs, repeat until the water covers your shoes. It's _much_ easier than CQD. Regards Marshall Hard to believe but Morse is still in use and required for certain classes of radio operators. Cheers Jorge ___ 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: Towards consensus on document format
On Tue, 16 Mar 2010, Marshall Eubanks wrote: On Mar 16, 2010, at 5:59 PM, Jorge Amodio wrote: I'd love to see you trapped in a basement after an earthquake with only a stick trying to remember how to tap S-O-S. That's easy. Three shorts and three longs, repeat until the water covers your shoes. As was said ... who can remember three dots, three dashes *AND* three dots ... pause and repeat ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Tue, Mar 16, 2010 at 05:05:13PM -0700, David Morris wrote: On Tue, 16 Mar 2010, Marshall Eubanks wrote: I'd love to see you trapped in a basement after an earthquake with only a stick trying to remember how to tap S-O-S. That's easy. Three shorts and three longs, repeat until the water covers your shoes. As was said ... who can remember three dots, three dashes *AND* three dots ... pause and repeat There was a great demonstration on a morning TV show a few months ago where they had two amateur radio operators racing against two people using a cell phone to send SMS messages, to see who could send a message faster from one person to another. The cell phone texters could use all of the standard text message abbrevations with the T9 input methods; and they had the advantage of using a cell phone keyboard with 12 buttons versus the radio operator's paddles. Guess who won? The morse code operators, of course, by a wide margin. Some times the old fashioned technology is the best. :-) - Ted (who is still using Emacs, not some fancy/shmancy WYSIWYG GUI tool to compose this message. :-) P.S. And I sometimes still use /bin/ed (which yes, will work on a teleprinter, to edit system files in single user mode; what's wrong with teleprinters anyway? I get most of my most productive work done using an xterm, which is really nothing more than a glass tty :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Phillip Hallam-Baker hallam at gmail dot com wrote: I do not need to have the evidence of 500 years of experience of using HTML to be able to demonstrate that HTML will be readable in 1000 years time. The difficulty of deciphering HTML is remarkably lower than the difficulty of deciphering Linear B (3500 years old), Egyptian hieroglyphs (last used 1600 years ago) or Mayan hieroglyphs (last used 400 years ago). The other silly aspect of this will it be readable in 1000 years argument is the supposition that the documents will sit, forgotten, for 1000 years until some future archaeologist digs them up and wants to decipher them. Obviously, if a newer and more wonderful format comes along that obsoletes PDF or HTML or whatever, there will surely be a utility (or, more likely, a spate of them) to convert data from the old format to the new format. The RFC series, and zillions of documents more valuable than 80% of the RFC series, will be converted and will exist in both old and new formats LONG before there is any risk of irreversible obsolescence. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Masataka Ohta mohta at necom830 dot hpcl dot titech dot ac dot jp wrote: FYI, your claim was: : Here is an example of PDF-A that uses nothing but ASCII characters: a PDF file whose *contents* were claimed to be pure ASCII See above. and now it is claimed that this demonstrates not only that the contents of a PDF file cannot be plain ASCII, but also that HTML is too unstable for a reduced-feature profile to be successful? Are you saying your PDF-A file is good but your definition of PDF-A is bad? But, broken definition is worse than broken tools, which, even more strongly, means we must not use profiled subset. I really don't understand what you are trying to prove here, except perhaps that I am a fool, and I don't understand in what way that benefits the IETF. Is it your claim that no PDF/A file could possibly exist without at least one non-ASCII character in its contents? Is it your claim that the document properties metadata, which of course doesn't exist for a plain-text RFC, is essential to the nature of a PDF/A RFC, and that no tool could exist that would not insert a trademark symbol or other non-ASCII character into this metadata? Or are you just trying to show that you are more clever than me? -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ http://is.gd/2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Tue, 2010-03-16, Doug Ewell wrote: The other silly aspect of this will it be readable in 1000 years argument is the supposition that the documents will sit, forgotten, for 1000 years until some future archaeologist digs them up and wants to decipher them. Obviously, if a newer and more wonderful format comes along that obsoletes PDF or HTML or whatever, there will surely be a utility (or, more likely, a spate of them) to convert data from the old format to the new format. The RFC series, and zillions of documents more valuable than 80% of the RFC series, will be converted and will exist in both old and new formats LONG before there is any risk of irreversible obsolescence. I am haunted by the reports I've heard of NASA plaintively requesting *anybody* to provide them with a 7-track tape machine to allow them to read old data tapes from the 1960's and 1970's. Not so much 1000 years as 40 years! -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Tue, Mar 16, 2010 at 07:58:17PM -0700, Bill McQuillan wrote: I am haunted by the reports I've heard of NASA plaintively requesting *anybody* to provide them with a 7-track tape machine to allow them to read old data tapes from the 1960's and 1970's. Not so much 1000 years as 40 years! I think that's a somewhat old story. See: http://investorshub.advfn.com/boards/read_msg.aspx?message_id=47354207 http://www.johnbordynuik.com/case-studies/mit http://www.johnbordynuik.com/case-studies/nasa Problem solved, with a dose of new technology. Did it cost extra money, because some folks didn't plan ahead and didn't convert these tapes sooner? Yes. But it was doable (And it had nothing to do with XML or teleprinter or Character set issues I can see the headlines now; Internet history lost forever because historians felt too 'personally insulted' to read 66-line formatted RFC's. :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of Robust Header Compression (rohc)
The Robust Header Compression (rohc) working group in the Transport Area has concluded. The IESG contact persons are Magnus Westerlund and Lars Eggert. The ROHC working group has successfully completed its charter and can now be closed. The ROHC WG has during the years produced a framework and a number of compression profiles for header compression supporting the most commonly used protocols possible to implement over a wide range of lower layers. IETF has produced specifications for PPP and IPsec tunnels. In addition to header compression also a signaling message compression protocol (SigComp) has been defined. Various supporting documents has also been produced. The ADs would like to thank everyone who participated in the work over the years. Especially the WG chairs Carl Knutsson, Lars-Erik Jonsson, Carsten Bormann and Mikael Degermark. The mailing list will remain open. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Better-Than-Nothing Security (btns)
The Better-Than-Nothing Security (btns) in the Security Area has concluded. The IESG contact person is Tim Polk. The mailing list will remain active. This working group is closed after successfully completing the most important items from the charter. The mailing list will be kept open for possible questions and discussions around BTNS. In particular, this mailing list is the preferred venue for discussion of any BTNS API documents. If drafted, the BTNS API documents will be submitted using the individual submission process. The ADs would like to thank everyone who has been involved in the BTNS specification work, the chairs, Sam Hartman who was the responsible AD when the BTNS working group was formed, and various reviewers who helped greatly improve the BTNS specifications. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
