Re: Why the normative form of IETF Standards is ASCII

Martin, Thanks for your great review! On 10-03-26 4:17 PM, "Martin Rex" wrote: > I downloaded the WG document ASCII I-D (14-pages) from > http://tools.ietf.org/id/draft-ietf... > loaded it into NRoffEdit, selected "Edit->Convert Text to NRoff", > spent about 30 minutes fixing the Table Of Conte

Re: Why the normative form of IETF Standards is ASCII

On 27.03.2010 00:17, Martin Rex wrote: ... If an I-D author has issues with idnits complaining about formatting, then the toolchain of that author is likely responsible for this shortcoming. ... Indeed; or the lack of a tool chain :-) ... IMHO, being able to do this without chasing around for

Re: Why the normative form of IETF Standards is ASCII

Andrew Sullivan wrote: > > On Sat, Mar 20, 2010 at 02:55:56PM -0800, Bob Braden wrote: > > > Drafts. That always seemed counter-productive to me. I am not sure I > > would characterize the problem as "serious", but it does seem t o warp > > common sense for the sake of bureaucratic uniformit

Re: Why the normative form of IETF Standards is ASCII

On Wed, Mar 24, 2010 at 11:56 PM, Stefan Santesson wrote: > One minor question. > > How do you use xml2rfc to edit a document when you don't have that document > in xml format? I've had luck with converting using xml2rfc-xxe (http://xml2rfc-xxe.googlecode.com/); you select the entire document, us

Re: Why the normative form of IETF Standards is ASCII

Maybe it's just me, but I couldn't find any files there. On Mar 25, 2010, at 12:03 AM, Stefan Santesson wrote: > Actually, there seems to be one here: > http://sourceforge.net/projects/rfc2xml/ > > Not sure how much of a good work it does. > > /Stefan > > > On 10-03-24 5:10 PM, "Julian Reschk

Re: Why the normative form of IETF Standards is ASCII

Actually, there seems to be one here: http://sourceforge.net/projects/rfc2xml/ Not sure how much of a good work it does. /Stefan On 10-03-24 5:10 PM, "Julian Reschke" wrote: > On 25.03.2010 00:56, Stefan Santesson wrote: >> Julian, >> >> One minor question. >> >> How do you use xml2rfc to e

Re: Why the normative form of IETF Standards is ASCII

On 25.03.2010 01:02, Stefan Santesson wrote: On 10-03-12 8:34 PM, "Julian Reschke" wrote: Because of the page breaks and the consistent presence of these headers and footers just before and after the page breaks, an accessibility tool should be able to recognize them as such. I agree it wou

Re: Why the normative form of IETF Standards is ASCII

On 25.03.2010 00:56, Stefan Santesson wrote: Julian, One minor question. How do you use xml2rfc to edit a document when you don't have that document in xml format? You don't. For example, if it was not originally created using xml2rfc. Somebody might have converted it (you may want to goo

Re: Why the normative form of IETF Standards is ASCII

On 10-03-12 8:34 PM, "Julian Reschke" wrote: >> Because of the page breaks and the consistent presence of these >> headers and footers just before and after the page breaks, an >> accessibility tool should be able to recognize them as such. > > I agree it would be nice if they did that. Do they

Re: Why the normative form of IETF Standards is ASCII

Julian, One minor question. How do you use xml2rfc to edit a document when you don't have that document in xml format? For example, if it was not originally created using xml2rfc. /Stefan On 10-03-22 2:58 PM, "Julian Reschke" wrote: > On 22.03.2010 22:28, Martin Rex wrote: >> ... >> With xml

Re: Using xml2rfc (was: Re: Why the normative form of IETF Standards is ASCII)

On Mar 23, 2010, at 6:12 AM, Doug Ewell wrote: > Martin Rex wrote: > >> If anything deserves the description "60's style document editing" then it >> is the current xml2rfc processing, which requires a whole bunch of extra >> software, lots of manual processing steps, reading of lots of docum

Re: Why the normative form of IETF Standards is ASCII

Masataka Ohta wrote: As many Japanese type Yen sign, when he actually want to input back slash, the JIS character of Yen sign is converted to unicode character of Yen sign, which is not back slash, which was the intention. I think this means that the user's kludge, in typing a yen sign to

Using xml2rfc (was: Re: Why the normative form of IETF Standards is ASCII)

Martin Rex wrote: If anything deserves the description "60's style document editing" then it is the current xml2rfc processing, which requires a whole bunch of extra software, lots of manual processing steps, reading of lots of documentation and plenty of time and desire for humiliation in o

Re: Why the normative form of IETF Standards is ASCII

Doug Ewell wrote: >> As many Japanese type Yen sign, when he actually want to input back >> slash, the JIS character of Yen sign is converted to unicode character >> of Yen sign, which is not back slash, which was the intention. > I think this means that the user's kludge, in typing a yen sign

Re: Why the normative form of IETF Standards is ASCII

On 22.03.2010 22:28, Martin Rex wrote: ... With xml2rfc 1, 2, 3, 4, 5 and 6 are all seperate, manual and painful steps that require all sorts of unspecified other software and require you to search around for information and read lots of stuff in order to get it working. The specific tools, thei

Re: Why the normative form of IETF Standards is ASCII

What I found strange that for many many years it was difficult to get started on writing an I-D, because of a lack of a decent tool to facilitate writing I-Ds. The processing steps in producing an I-D are rougly this: 1. get document template 2. edit document 3. spell checking 4.

Re: Why the normative form of IETF Standards is ASCII

We issue errata for RFCs. Most errata address a substantive defect in the text that would affect the protocol. The RFC may be 'authoritative' (whatever that is meant to mean) but the errata is almost certainly what someone would want to actually implement to make the protocol work. I remember a c

Re: Why the normative form of IETF Standards is ASCII

Masataka Ohta wrote: As many Japanese type Yen sign, when he actually want to input back slash, the JIS character of Yen sign is converted to unicode character of Yen sign, which is not back slash, which was the intention. I think this means that the user's kludge, in typing a yen sign to g

Re: Why the normative form of IETF Standards is ASCII

Doug Ewell wrote: > See, if you use any encoding of Unicode, you won't have this problem, > because U+005C is unequivocally the backslash and U+00A5 is > unequivocally the yen sign. There are no context-dependent "duals" in > Unicode. Character issues are a lot more complicated than you can i

Re: Why the normative form of IETF Standards is ASCII

Masataka Ohta wrote: Yes, but, ASCII back slash is already a little too much enough for us Japanese, because, in Japan, JIS Latin, which assigne Yen sign to the code point of back slash, is so widely used. See, if you use any encoding of Unicode, you won't have this problem, because U+005C

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: >> What exactly is the purpose of "a few non-ASCII characters everybody can >> display"? And while the environments that I use are mostly capable >> to display ISO-Latin-1, I do _NOT_ know names for the majority of symbols >> from> 128, and would have severe difficulties di

Re: Why the normative form of IETF Standards is ASCII

On 20.03.2010 00:26, Martin Rex wrote: ... When I submitted my very first I-D last November, it took me about 10 minutes to fix the few issues that idnits reported. If you have significantly more problems, then maybe you are using the wrong tool to write I-Ds. Try NRoffEdit. It will take care

Re: Why the normative form of IETF Standards is ASCII

On 19.03.2010 09:47, Arnt Gulbrandsen wrote: ... (That would also help with the other kind of cross references, "see [19] section 4.2" when [19] is updated. The likelihood that 4.2 is renumbered shrinks, since xml2rfc can warn when it happens.) ... The preferred RFC editor style is symbolic nam

Re: Why the normative form of IETF Standards is ASCII

On 20.03.2010 00:45, Martin Rex wrote: Julian Reschke wrote: I don't buy that. We've got something like 1 billion people on the planet running web browsers, and I'm pretty confident we can find a few non-ASCII characters everybody can display which could be used in examples. What exactly is t

Re: Why the normative form of IETF Standards is ASCII

Andrew Sullivan wrote: > I had, in the past year, two different DNSEXT participants send me > frustrated email because of the idnits checks. The people in question > were both long-time contributors to the IETF with perhaps > ideosyncratic toolchains. Neither of them was using xml2rfc, and > nei

Re: Why the normative form of IETF Standards is ASCII

On Sat, Mar 20, 2010 at 02:55:56PM -0800, Bob Braden wrote: > Drafts. That always seemed counter-productive to me. I am not sure I > would characterize the problem as "serious", but it does seem t o warp > common sense for the sake of bureaucratic uniformity.) I got some mail off-list about

Re: Why the normative form of IETF Standards is ASCII

There are two versions of ID-nits that should be used: 1) one when you're working on getting the words right, and 2) one when you're working on getting the formatting right. #1 should be used when you're at the beginning of the lifecycle. The requirements for it *should* *be* *minimal*. #2 s

Re: Why the normative form of IETF Standards is ASCII

+1 Bob Braden (PS: The IESG has chosen to impose the RFC editing rules on all Internet Drafts. That always seemed counter-productive to me. I am not sure I would characterize the problem as "serious", but it does seem t o warp common sense for the sake of bureaucratic uniformity.) In my v

Re: Why the normative form of IETF Standards is ASCII

Martin Rex wrote: > Discussing non-ASCII characters often requires the use of > unicode codepoints to avoid ambiguities and the lack of familiarity > of most people of this planet with the glyphs on most unicode codepoints. Avoid ambiguities with unicode? > Describing a unicode codepoint by its

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: > > I don't buy that. We've got something like 1 billion people on the > planet running web browsers, and I'm pretty confident we can find a few > non-ASCII characters everybody can display which could be used in examples. What exactly is the purpose of "a few non-ASCII ch

Re: Why the normative form of IETF Standards is ASCII

On Mar 19, 2010, at 3:26 PM, Martin Rex wrote: As previously mentioned, I gave up on trying to _install_ xml2rfc one hour after downloading it. I was writing the third page of my I-D one hour after downloading NRoffEdit. Even if you're one of those rare birds who has difficulty installing xml2

Re: Why the normative form of IETF Standards is ASCII

Andrew Sullivan wrote: > > On Fri, Mar 19, 2010 at 01:39:38PM -0700, Bob Braden wrote: > > It would be good if RFC authors put atleast as much care into the > > clarity and organization of their contents as you are devoting to a > > discussion of the formatting. The contents are what matter,

Re: Why the normative form of IETF Standards is ASCII

On Fri, Mar 19, 2010 at 01:39:38PM -0700, Bob Braden wrote: > It would be good if RFC authors put atleast as much care into the > clarity and organization of their contents as you are devoting to a > discussion of the formatting. The contents are what matter, and fancy > formatting may (or m

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

On 19 mrt 2010, at 12:02, Dave Cridland wrote: > Why care about a normative output? You change the subject to talk about using > non-normative representations already, why care about a normative output *at > all*? You have a point. But it's in the subject line... > Let's concentrate on a norma

Re: Why the normative form of IETF Standards is ASCII

It would be good if RFC authors put atleast as much care into the clarity and organization of their contents as you are devoting to a discussion of the formatting. The contents are what matter, and fancy formatting may (or may not) be a distraction from the more important issues of contents.

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

> The virtues (or lack thereof) of xml2rfc are a separate discussion. The > question isn't how we generate the normative output, but what the normative > output should be. Seems to me that this discussion has reached the point at which running code is needed in order to get any further. May I s

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

On 3/19/2010 3:29 AM, Iljitsch van Beijnum wrote: > On 19 mrt 2010, at 5:05, John Levine wrote: > > > xml2rfc does a pretty good job of capturing what needs to be in an > > RFC, so that is the strawman I would start from. > > The virtues (or lack thereof) of xml2rfc are a separate discussion. > The

Re: Why the normative form of IETF Standards is ASCII

Maybe I'm not enough of a amateur lawyer, but has "authoritative" been a practical issue, i.e., has there been confusion or legal action because one rendition (say, PDF) differed in some trivial aspect from another (e.g., ASCII)? Pragmatically, one could simply state that one form (say, good-ol

A state of spin ... presented in ASCII (was: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII)

At 04:02 19-03-10, Dave Cridland wrote: The IAB made a clear statement that we need i18n support, yet over a decade after RFC 2130 or RFC 2825, the RFCs themselves still have a strict ASCII limitation. Sure, that wasn't mentioned at the time, but does nobody else find this plain shameful? As se

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

Ohta san, Let me guess: You're not a big fan of IDNs either, right? 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 Fri, 19 Mar 2010, Masataka Ohta wrote:

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

Iljitsch van Beijnum wrote: >>1. I cannot print them correctly on either Windows or Mac. >>2. I cannot view them at all on the mobile device > These two issues can easily be solved by using the PDF or HTML versions. Simple plain ASCII text is just fine. >>3. I cannot enter the name of an autho

Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

On Fri Mar 19 10:29:04 2010, Iljitsch van Beijnum wrote: On 19 mrt 2010, at 5:05, John Levine wrote: > xml2rfc does a pretty good job of capturing what needs to be in an > RFC, so that is the strawman I would start from. The virtues (or lack thereof) of xml2rfc are a separate discussion. The

Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII

On 19 mrt 2010, at 5:05, John Levine wrote: > xml2rfc does a pretty good job of capturing what needs to be in an > RFC, so that is the strawman I would start from. The virtues (or lack thereof) of xml2rfc are a separate discussion. The question isn't how we generate the normative output, but wha

Re: Why the normative form of IETF Standards is ASCII

On 03/19/2010 01:49 AM, Tony Finch wrote: Boggle. A major advantage of xml2rfc compared to HTML is that it does the numbering for you, and you don't have to manually maintain cross references. I don't have any problem editing the source in one window while viewing the presentation document in an

Re: Why the normative form of IETF Standards is ASCII

>> If we really want to do something in this space first of all we >need to agree on the problem, then on the requirements and THEN we >can have a useful discussion. I thought the waterfall model of software design was discredited in about 1975. Rough consensus and running code, throwing darts at

Re: Why the normative form of IETF Standards is ASCII

>I don't have any problem editing the source in one window while >viewing the presentation document in another. Window? My ASR-33 doesn't have any windows. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Why the normative form of IETF Standards is ASCII

On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum wrote: > If we really want to do something in this space first of all we need to agree > on the problem, then on the requirements and THEN we can have a useful > discussion. So far the only thing I hear is assertions offered without any >

Re: Why the normative form of IETF Standards is ASCII

On 18 Mar 2010, at 20:41, Arnt Gulbrandsen wrote: On 03/18/2010 09:37 PM, Julian Reschke wrote: And how are numbered lists a problem? I thought it was a pain because I got comments referring to and the file I edited contained no . xml2rfc generated numbers, people used them to me, I d

Re: Why the normative form of IETF Standards is ASCII

On 03/18/2010 01:52 PM, Julian Reschke wrote: > On 18.03.2010 21:41, Arnt Gulbrandsen wrote: >> On 03/18/2010 09:37 PM, Julian Reschke wrote: >>> And how are numbered lists a problem? >> >> I thought it was a pain because I got comments referring to and the >> file I edited contained no . xml2rfc

Re: Why the normative form of IETF Standards is ASCII

On 18.03.2010 21:41, Arnt Gulbrandsen wrote: On 03/18/2010 09:37 PM, Julian Reschke wrote: And how are numbered lists a problem? I thought it was a pain because I got comments referring to and the file I edited contained no . xml2rfc generated numbers, people used them to me, I didn't see the

Re: Why the normative form of IETF Standards is ASCII

On 03/18/2010 09:37 PM, Julian Reschke wrote: And how are numbered lists a problem? I thought it was a pain because I got comments referring to and the file I edited contained no . xml2rfc generated numbers, people used them to me, I didn't see them in the source. In general I think the RF

Re: Why the normative form of IETF Standards is ASCII

On 18.03.2010 21:25, Iljitsch van Beijnum wrote: ... That is simply incorrect, which can easily be checked by looking at the XML source of a spec. People make mistakes implementing today's text. If they have to implement from XML source where they have to interpret things like escape codes a

Re: Why the normative form of IETF Standards is ASCII

On 18 mrt 2010, at 20:59, Julian Reschke wrote: >> The XML in itself can't be interpreted by a human to the level needed to >> create a compliant implementation, although it deceptively looks like maybe >> it could. Of course human readability also doesn't exist for pretty much >> anything othe

Re: Why the normative form of IETF Standards is ASCII

On 18.03.2010 20:24, Iljitsch van Beijnum wrote: On 18 mrt 2010, at 2:43, Richard Barnes wrote: +1 Making the XML normative would be an abomination. The XML in itself can't be interpreted by a human to the level needed to create a compliant implementation, although it deceptively looks like

Re: Why the normative form of IETF Standards is ASCII

On 18 mrt 2010, at 2:43, Richard Barnes wrote: > +1 Making the XML normative would be an abomination. The XML in itself can't be interpreted by a human to the level needed to create a compliant implementation, although it deceptively looks like maybe it could. Of course human readability also

Re: Why the normative form of IETF Standards is ASCII

between the XML and the final output. If we could agree that the final XML was authoritative, What, precisely, do you mean here? Do you mean that there would be NO text form of an RFC that was authoritative, or do you mean that BOTH the xml2rfc form and some text-equivalent form (say, .txt or

Re: Why the normative form of IETF Standards is ASCII

John R. Levine wrote: between the XML and the final output. If we could agree that the final XML was authoritative, John, What, precisely, do you mean here? Do you mean that there would be NO text form of an RFC that was authoritative, or do you mean that BOTH the xml2rfc form and some t

Re: Why the normative form of IETF Standards is ASCII

On Thu Mar 18 03:27:30 2010, Phillip Hallam-Baker wrote: That would meet most of my issues, provided of course that the XML2RFC format was published. There's a rfc2629bis at/as http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html Is there anything you feel that's not covering?

Re: Why the normative form of IETF Standards is ASCII

That would meet most of my issues, provided of course that the XML2RFC format was published. Zero time spent going to an editable format is better than any amount of 'easy conversion'. On Wed, Mar 17, 2010 at 9:03 PM, Tony Hansen wrote: > +1 > > On 3/17/2010 12:18 PM, John R. Levine wrote: >> >>

Re: Why the normative form of IETF Standards is ASCII

+1 On Mar 17, 2010, at 9:03 PM, Tony Hansen wrote: +1 On 3/17/2010 12:18 PM, John R. Levine wrote: If we could agree that the final XML was authoritative, and if necessary let them hire someone to fix xmlrfc so it can produce the text version without hand editing or postprocessing, that woul

Re: Why the normative form of IETF Standards is ASCII

+1 On 3/17/2010 12:18 PM, John R. Levine wrote: If we could agree that the final XML was authoritative, and if necessary let them hire someone to fix xmlrfc so it can produce the text version without hand editing or postprocessing, that would be a big step forward.

Re: Why the normative form of IETF Standards is ASCII

Indeed, I know plenty of people these days who have no idea today how to produce an ASCII file with only tab, CR, and LF formatting characters. Type. Save as text. How hard is that? Good guess, but wrong. If you do that, you will still generally get various non-ASCII quotes and punctuation m

Re: Why the normative form of IETF Standards is ASCII

On 2010-3-17, at 8:48, Iljitsch van Beijnum wrote: > I have actually written a few drafts that way. The text part isn't hard, but > the hard breaks at every line are, and the hard breaks at every page even > more so. Tools do create those don't exist in today's world. they do, e.g., something l

Re: Why the normative form of IETF Standards is ASCII

On 12 mrt 2010, at 6:58, John Levine wrote: > Indeed, I know plenty of people these days who have no idea today how > to produce an ASCII file with only tab, CR, and LF formatting > characters. Type. Save as text. How hard is that? I have actually written a few drafts that way. The text part isn

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:

Re: Why the normative form of IETF Standards is ASCII

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 ..

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: > > > Printing the documents with Microsoft Word is not that difficult. > > Load it as .txt, remove two newlines at the beginning of the > > title page, select page margins at 1"/1" left&right, font > > courier new and font size 10 throughout should work on A4 paper. > > Prin

Re: Why the normative form of IETF Standards is ASCII

On 15.03.2010 21:01, Martin Rex wrote: ... Are there numbers available from the RFC Editor about the use of XML vs nroff for document subissions during the past 1/2 years? ... That would be interesting. ... So the big plus for the ASCII document version is that an author can spend his time en

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: > > On 14.03.2010 19:45, Phillip Hallam-Baker wrote: > > > > Since the preferred submission formats are XML or nroff, I see no reason > > that the HTML version could not be generated from the XML. Are there numbers available from the RFC Editor about the use of XML vs nroff

Re: Why the normative form of IETF Standards is ASCII

On 14.03.2010 19:45, Phillip Hallam-Baker wrote: You can submit the HTML, the problem is that it seems to go in the bit bucket. Since the preferred submission formats are XML or nroff, I see no reason that the HTML version could not be generated from the XML. The problem seems to be that the RF

Re: Why the normative form of IETF Standards is ASCII

You can submit the HTML, the problem is that it seems to go in the bit bucket. Since the preferred submission formats are XML or nroff, I see no reason that the HTML version could not be generated from the XML. The problem seems to be that the RFC editor insists on using the XML to generate nroff

Re: Why the normative form of IETF Standards is ASCII

Funny, I don't think anyone was suggesting PDF/A. The format most people have been suggesting is HTML. Donald brought up PDF/A as a strawman at the start of this discussion. And the fact is that even though many, many people submit HTML versions of their drafts it is not possible to retrieve them

Re: Why the normative form of IETF Standards is ASCII

On Sun, Mar 14, 2010 at 10:35 AM, Jari Arkko wrote: > I don't want to enter a discussion about the merits of PDF/A over HTML at > this time. For the record, if the IETF were to entertain the notion of blessing a format other than legacy-ASCII, I'd be strongly against any form of PDF. It seems

Re: Why the normative form of IETF Standards is ASCII

Are you asking about I-Ds or RFCs? I cannot see any HTML version of any I-D in the directory, and I think it should be easy to enable that (just as we have enabled PDF submission). Getting the RFC Editor to publish your own HTML is a different matter, because then we are talking about permanent

Re: Why the normative form of IETF Standards is ASCII

On 3/14/2010 11:35 AM, Jari Arkko wrote: I do agree with you that it would be nice if you could submit HTML. If its true that its currently prohibited to look at it or subimt it, then that is something that could be fixed. That's certainly a reasonable view, but it raises the concern about

Re: Why the normative form of IETF Standards is ASCII

Phillip, I don't want to enter a discussion about the merits of PDF/A over HTML at this time. However, I do agree with you that it would be nice if you could submit HTML. If its true that its currently prohibited to look at it or subimt it, then that is something that could be fixed. I can tak

Re: Why the normative form of IETF Standards is ASCII

On 14.03.2010 01:39, Doug Ewell wrote: ... A different PDF creation program other than Word might not insert the registered-trademark symbol anyway. Or it could be edited out, if this is truly a deal-breaker. But I thought the contents were what was important. PDF is a binary format and there are

Re: Why the normative form of IETF Standards is ASCII

Running code, actual interest to deploy, and an incremental deployment model would probably take this matter further than the annual religious argument :-) Those who feel the pain should build/select tools and demonstrate that (a) they can produce high-quality PDF/A, (b) that it provides addit

Re: Why the normative form of IETF Standards is ASCII

Doug Ewell wrote: >> I'm afraid the PDF file contains non-ASCII character of circled R in >> metadata for pdf:Creator. >> Thank you for a convincing demonstration to deny yourself. > Metadata? Is that what we're talking about? Yes. > PDF is a binary format and there are lots of other bytes i

Re: Why the normative form of IETF Standards is ASCII

[3] Here is an example of PDF-A that uses nothing but ASCII characters: http://www.ewellic.org/ascii-only.pdf I've replaced this with another PDF file created by a program (Acrobat Distiller 6.0.1) whose name, as displayed in the Properties dialog, doesn't include a non-ASCII symbol. Of cou

Re: Why the normative form of IETF Standards is ASCII

Masataka Ohta wrote: [3] Here is an example of PDF-A that uses nothing but ASCII characters: http://www.ewellic.org/ascii-only.pdf I'm afraid the PDF file contains non-ASCII character of circled R in metadata for pdf:Creator. Thank you for a convincing demonstration to deny yourself. M

Re: Why the normative form of IETF Standards is ASCII

Doug Ewell wrote: > came to be twisted by Ohta-san so imaginatively. I'm simply realistic. > [3] Here is an example of PDF-A that uses nothing but ASCII characters: > http://www.ewellic.org/ascii-only.pdf I'm afraid the PDF file contains non-ASCII character of circled R in metadata for pdf:Crea

Re: Why the normative form of IETF Standards is ASCII

Masataka Ohta wrote: The problem with email is people use html way too much. TXT -> HTML -> TXT does not work reliable. Too many one way transformations. That's enough to deny the following statement of Doug Ewell; You could have HTML or PDF-A that uses nothing but ASCII characters. I

Re: Why the normative form of IETF Standards is ASCII

Since we are destined to keep pretending that character sets and document formats are one and the same... Martin Rex wrote: all unicode codepoints from their glyphs (and a number of them can not be distinguished by their glyphs), and even worse, most machines/environments do not even have fo

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 04:42, Phillip Hallam-Baker wrote: +1 on all of this, one comment though: > ... > As a pragmatic fact, XML2RFC has practically replaced the ASCII format > RFC as the canonical form already. The only obstacles are the IETF > tools that deliberately and insultingly make it diffic

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 23:16, Martin Rex wrote: ... The IETF is not in the publishing business, and if you want to get a scientific paper with pretty diagrams, math formulas, photos in languages other than english and filled with fancy characters from all over unicode, then you probably should go to eithe

Re: Why the normative form of IETF Standards is ASCII

Tim Bray wrote: > > On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex wrote: > > Martin describes a planet on which nroff formatting semantics are > considered to have current relevance, in which it's hard to look at 4 > or 5 HTML documents simultaneously, in which people don't care which > character

Re: Why the normative form of IETF Standards is ASCII

Mark Andrews wrote: > The problem with email is people use html way too much. TXT -> > HTML -> TXT does not work reliable. Too many one way transformations. That's enough to deny the following statement of Doug Ewell; You could have HTML or PDF-A that uses nothing but ASCII cha

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 04:42, Phillip Hallam-Baker wrote: +1 on all of this, one comment though: ... As a pragmatic fact, XML2RFC has practically replaced the ASCII format RFC as the canonical form already. The only obstacles are the IETF tools that deliberately and insultingly make it difficult to acce

Re: Why the normative form of IETF Standards is ASCII

A) I think that says much more about the low quality of a particular PDF reader than about PDF itself. The point solution is obvious: never use that piece of software. B) For many of us who need to refer to IETF standards while looking at the world through a 24x80 ssh session, ASCII is most conv

Re: Why the normative form of IETF Standards is ASCII

What concerns me rather more is the observed fact that rather a lot of implementations appear to be built on the basis of the text in the O'Reilly Nutshell guides than the RFCs which we hope to be regarded as canonical. I certainly don't read ASCII RFCs or IDs as source material if I can help it.

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 22:25, Mark Andrews wrote: ... The problem with email is people use html way too much. TXT -> HTML -> TXT does not work reliable. Too many one way transformations. ... Yes, agreed. I don't like HTML email either. But what does this have to do with IETF specification formats?

Re: Why the normative form of IETF Standards is ASCII

In message <4b9aa7ff.4000...@gmx.de>, Julian Reschke writes: > On 12.03.2010 21:41, Masataka Ohta wrote: > > Doug Ewell wrote: > > > >> A space character (which looks like an ordinary U+0020 space to me, in > >> both the plain-text message I received and in the Web archive) got > >> erroneously co

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: > What *is* a "pure ASCII profile of non-ASCII-capable PDF"? As my point is its impossible to have one, ask Doug Ewell who says: You could have HTML or PDF-A that uses nothing but ASCII characters. Mas

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 22:06, Tim Bray wrote: On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex wrote: Martin describes a planet on which nroff formatting semantics are considered to have current relevance, in which it's hard to look at 4 or 5 HTML documents simultaneously, in which people don't care which c

Re: Why the normative form of IETF Standards is ASCII

Julian Reschke wrote: > > I'm at the end of your mail, but you haven't told me how printing the > example document I pointed to worked for you. Did you try? If not, why not? You mean this one: > It would be nice if you could elaborate on what the problem is. Try, for > instance, printing

Re: Why the normative form of IETF Standards is ASCII

On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex wrote: Martin describes a planet on which nroff formatting semantics are considered to have current relevance, in which it's hard to look at 4 or 5 HTML documents simultaneously, in which people don't care which characters are used to write their names

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 21:41, Masataka Ohta wrote: Doug Ewell wrote: A space character (which looks like an ordinary U+0020 space to me, in both the plain-text message I received and in the Web archive) got erroneously converted to a question mark in Tim's plain-text mail. It is not a question mark ch

Re: Why the normative form of IETF Standards is ASCII

Doug Ewell wrote: > A space character (which looks like an ordinary U+0020 space to me, in > both the plain-text message I received and in the Web archive) got > erroneously converted to a question mark in Tim's plain-text mail. It is not a question mark character but a some strange non-ASCII c

Re: Why the normative form of IETF Standards is ASCII

On 12.03.2010 19:43, Martin Rex wrote: ... No, it does not. It points to an HTML document that was converted from the original TXT version (on the server, by Henrik's rfcmarkup script). Whether the converted document is long-term cached or converted on the fly is an insignificant implementatio

  1   2   >