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 question isn't how we generate the normative output, but what the > normative output should be. Agreed, the issue is two fold - the data type and the data format for submission. The content itself is irrelevant to this conversation since that is controlled by the publishing desk. > > On 19 mrt 2010, at 2:04, Tim Bray wrote: > > > On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum > > <iljitsch@xxxxxxxxx> wrote: > > > >> So far the only thing I hear is assertions offered without any > foundation that the current format is problematic The assertion is that something more than TEXT needs to be acceptable as far as the packaging goes especially with regard to diagramming and drawings inside of work product. > > > OK, one more time, let me enumerate the problems with the current > > format. I agree that you may not perceive them as problems, but they > > are problems for me: > > > 1. I cannot print them correctly on either Windows or Mac. Why not? Text printing is text printing. PDF's on Mac look just like PDF's on Windows do too AFAIK... and Adobe would be in a world of hurt if this was not so, so... > > 2. I cannot view them at all on the mobile device Why do you need to? Do you do design review work on your mobile device? Most of them dont have enough screen space to make that efficient so again what is the real issue here? or is it about being able to just utter the words "IETF processes allow collaboration for every device on the Internet"... > > These two issues can easily be solved by using the PDF or HTML > versions. Any paginated ASCII can be turned into a PDF easily and > automatically. There are different HTMLizations of RFCs, some better > some worse. Creating an HTML version is harder than a PDF version > without an xml2rfc source but for most RFCs there is a decent HTML > version available somewhere. > > The PDF versions can be obtained from the RFC Editor if you search > specifically for them, but in most places only the text versions show > up. It would help a lot if the HTML and PDF versions were easier to > find. Maybe the secretariat could put this on their todo list? > > > 3. I cannot enter the name of an author correctly if that name > > includes non-ASCII characters.But even if you could, would you? I > can't do anything useful with names written in anything other than > latin characters (well, maybe also Greek). I wouldn't even know how to > type them if I wanted to search for them. So at the very least all > names would still have to appear in latin script and the non-latin > form would be extra. Is the tiny benefit of having the "real" name > there as a non-normative extra really enough to change what we've been > doing for 40 years? yes... but that also is another issue. > > > 4. I cannot provide an actual illustrative working example of the use > > of non-ASCII text in Internet Protocols. > > Correct interpretation of things like UTF-8 is highly dependent on > context. On many systems a plain text file with non-7bit-ASCII > characters won't be displayed as intended by default. So it would be > necessary to go to HTML with &#; encodings of these characters or PDF > to be reasonably sure they show up correctly. To me, PDF is > unacceptable because it's even harder to display on devices other than > computers with large screens or paper and it can't be decoded without > complex tools. And switching to HTML just for this purpose isn't worth > it to me. But then, I've never written a draft that required non-ASCII > characters so that's easy for me to say. > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf >
begin:vcard fn:Todd Glassey n:Glassey;Todd email;internet:TGlassey@xxxxxxxxxxxxx x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf