Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Yaakov Stein schrieb:
 

I would say that getting always the same printout is a non-goal.


Why? As has been stated previously, in most SDOs the "printed page"
is the final word. One of the many inconveniences of xml2rfc is the need
to add "vspace blankLines" to avoid unfortunate page breaks.


Because it's sufficient to generate the ASCII version once on 
publication and then keep it. Keeping the source is essential for 
completely separate tasks (meta data extraction, document revision, 
generating other formats such as HTML or PDF).


You're comparing apples and oranges here. 
For instance, you could use XSL-FO (an XML format...) which also is

closer to presentation markup than the RFC2629 XML format.

Why should the IETF be inventing new tools to create documents at all?
Why aren't we focusing on developing protocols for the IP world,
and adopting existing tools for the mundane task of document creation?


So far the IETF hasn't done that. The format is ASCII.

One good reason to use a specific XML grammar is that when the only 
thing that's available is a presentation-oriented format (such as Word 
or PDF), it gets *much* harder to do meaningful things with the source. 
And that's one of the reasons why volunteers maintain xml2rfc (both the 
format itself and various implementations). Speaking of which, that's 
probably the reason why the W3C is doing the same with their xmlspec XML 
format.


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> I would say that getting always the same printout is a non-goal.

Why? As has been stated previously, in most SDOs the "printed page"
is the final word. One of the many inconveniences of xml2rfc is the need
to add "vspace blankLines" to avoid unfortunate page breaks.

>You're comparing apples and oranges here. 
>For instance, you could use XSL-FO (an XML format...) which also is
closer to presentation markup than the RFC2629 XML format.

Why should the IETF be inventing new tools to create documents at all?
Why aren't we focusing on developing protocols for the IP world,
and adopting existing tools for the mundane task of document creation?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]

[C. M. Heard]

[ follow-ups to IETF discussion list please]

Of the three possible ways forward suggested by this draft, I think that
the only one that's likely to get done is this one:

   1.  Agree that, apart from day to day efforts to improve efficiency,
   the problems with the existing standards track are not serious
   enough to justify the effort needed to make substantial changes.
   Conclude that [RFC3774] exaggerated the problem and we only need
   to make a relatively minor set of clarifications to BCP 9
   [RFC2026].

I say this because the newtrk WG has already tried to do the other two
things that were suggested (focusing on document relationships and
reworking the standards track) and failed.  The deafening silence on
the WG mailing list suggests to me that the energy has run out of this
WG and it should be closed.

I believe that two modifications (not clarifications) to RFC 2026
would suffice:

- drop the expectation that a document will necessarily ever advance,
and drop the requirement for periodic reviews of documents at PS or DS;

- drop the "no normative downrefs" rule.

This last should be done with an absolute minimum of fuss and with no
imposition of requirements to put special notes in the documents
about downrefs.  If we can't agree on that, then I would settle for
just the first modification.  That would at least get our documented
procedures more in line with the reality that we practice.

Mike Heard


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Robert Elz]

Date:Sat, 17 Jun 2006 21:40:06 -0700
From:Joe Touch <[EMAIL PROTECTED]>
Message-ID:  <[EMAIL PROTECTED]>

  | That's a problem when it changes page numbers (which end up being as
  | useful as semantic tags) or figures. Or (as importantly) template or
  | boilerplate text.

That's only true if the purpose of re-processing is to make the original
document again for some reason - which would only be useful if the
formatted version were not to be archived, but only the source, and I
don't believe anyone is suggesting that.

Archiving the source is useful for people who want to make revisions
 - certainly that is possible without the source, and for some source formats
and some later editors, ignoring the source and using the formatted
version might even be preferable - but not always, for many, having the
source available makes things much easier.

If you accept that the purpose of archiving the source is to ease the
production of a revised document, and not to reproduce the original unchanged,
then whether or not the formatting tool would produce the original,
unchanged, is completely irrelevant.

I'm not entirely sure what any of this has to do with the question of
allowing non-ascii normative formats, but it seems to be what this
discussion has turned into, so ...

kre


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Cullen Jennings]

On Jun 15, 2006, at 9:13 AM, Keith Moore wrote:

PDF used to be a free (as in beer), well-documented, relatively  
unencumbered, reasonably portable format.  Nowadays there are a  
number of compatibility problems between generators and viewers,  
which appear to be mostly due to Adobe's introduction of DRM to the  
PDF format.


PDF has had many portability problems to do with fonts and licensing  
of fonts long before any DRM was introduced.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Joe Touch]

Stephane Bortzmeyer wrote:
> On Fri, Jun 16, 2006 at 03:46:16PM -0700,
>  Joe Touch <[EMAIL PROTECTED]> wrote 
>  a message of 85 lines which said:
> 
>>  - edit source code (argh - back to the stone age)
> 
> I always assumed that most people involved in IETF edit source code
> daily (I did not say "full-time", I said "at least daily, or, let's be
> gentle, weekly").
> 
> Was I wrong?

I stopped editing document source code in 1986. The equivalent for
programming is editing assembler. Same thing. Not since the mid 1980s.

> And editing (in their raw, text-only, form) document formats like
> LaTeX or DocBook or HTML or RFC 2629 is much easier than
> editing source code.

They're equally antiquated to me; they put me in direct contact with a
level of internal structure that I don't feel gives me more control,
just more nuisance.

Joe



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Clement Cherlin schrieb:

...
Unicode Box Drawing

┌┐
│ This is a box  │
├┤
│With another box│
│   underneath   │
└┘
...


I like that. In fact I like it so much that I did add some machinery to 
rfc2629.xslt that helps in producing those (based on existing ASCII line 
art). Example at:




Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Yaakov Stein schrieb:
 

How about Tex?



It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.


It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes perfectly good diagrams,
and the source is pure future-proof ASCII.


I would say that getting always the same printout is a non-goal.


And there are advanced tools for editing and comparison on all platforms

of which I know, for those who desire something a bit stronger than vi
and grep.

As I have said before, if we decide on TeX instead of XML
we solve all the problems.


You're comparing apples and oranges here. For instance, you could use 
XSL-FO (an XML format...) which also is closer to presentation markup 
than the RFC2629 XML format.


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> How about Tex?

> It is as old as the internet and you can use vi to read and edit.
> You still can use grep to scan all old documents to find something.

It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes perfectly good diagrams,
and the source is pure future-proof ASCII.

And there are advanced tools for editing and comparison on all platforms

of which I know, for those who desire something a bit stronger than vi
and grep.

As I have said before, if we decide on TeX instead of XML
we solve all the problems.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Hallam-Baker, Phillip]

> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] 

> There is a slight difference here: the earth hasn't seen any 
> successful demolishion attempts in the last 4.5 billion 
> years, while nearly any word processing document format from 
> the 1990s can't be read properly. In many cases the text 
> itself can be retrieved but there is almost always loss of 
> some or even all formatting. I gather that the current 
> version of Word can't read documents made by all previous 
> versions of itself successfully.

Name one format that was intended for use as an archival document format that 
is unreadable.

> I'm convinced that the success of the TCP/IP and web families 
> of standards has a great deal to do with the fact that the 
> standards documents involved are freely and easily available.

The Web standards were always on the Web in HTML.


> > The output of the IETF is simply not that critical for this 
> level of 
> > concern to be warranted. RFCs are exactly that, requests 
> for comment.
> 
> Go ask the people at the company you work for how important 
> they think their GTLD servers are, and how critical RFCs 791, 
> 768 and 1035 (to name a few old ones) are for their continued 
> operation.

Another bad example. The company standard for internal documents is Microsoft 
Word and Powerpoint.

I was under the impression that the divergence between the DNS standards and 
reality was sufficiently great that any documentation has to be the starting 
point for regression testing and QA rather than gospel. Certainly this is the 
case in the PKI world.


> > The real standards are and will always be set by running code.
> 
> This is so absurd that I don't even know what to say.
> 
> > Without continued maintenance the value of standards is 
> quickly lost 
> > in any case. RFC 822 has long since ceased to be the Internet email 
> > standard, it is of historic interest only. The same is 
> close to being 
> > the case for RFC 2822 as well.
> 
> That's nice. But I doubt you're going to be able to read that 
> email message exchanged through the latest version of the 
> SMTP protocol without some support for RFC 894 along the way.
> 
> > The underlying fallacy here is that the documents are holy 
> scriptures, 
> > they are not, they are merely an engineering tool to effect an 
> > engineering outcome.
> 
> > Talk about what may happen in fifty or a hundred years time 
> is simply 
> > an ego trip. Its like those folk who in the dotcom boom took out 
> > million dollar key man insurance. It had nothing to do with 
> the damage 
> > that might be done to the company if they died unexpectedly 
> it was a 
> > pure ego trip from start to finish.
> 
> It's the other way around. Time and time again, when an 
> engineer thought "well, by that time surely the system will 
> be replaced" this turned out to be a mistake. Is Y2K really 
> that long ago that we don't remember that lesson?
> 
> By the way: I happened to see a documentary on sky scrapers 
> on the BBC the other night. I was surprised to see that the 
> Woolworth building in New York (built in 1913) still has the 
> original elevator machinary in operation. It would suck to 
> have to replace a bunch of elevators because you don't have 
> the documentation to prove that they're still up to code...
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Iljitsch van Beijnum]

On 18-jun-2006, at 16:20, Hallam-Baker, Phillip wrote:


It's not _that_ bizarre. Suppose that we decide to allow
publishing RFCs in PDF only. Suppose that within the next few
years some company comes up with a replacement for PDF that
is better is some important regard so that everyone switches
to the new format.


And suppose some Vogons came along and demolished the planet to  
make way for a hyperspace bypass.


There is a slight difference here: the earth hasn't seen any  
successful demolishion attempts in the last 4.5 billion years, while  
nearly any word processing document format from the 1990s can't be  
read properly. In many cases the text itself can be retrieved but  
there is almost always loss of some or even all formatting. I gather  
that the current version of Word can't read documents made by all  
previous versions of itself successfully.


The idea that any of the formats being discussed will become  
impossible to read is silly. There are billions of HTML document  
and hundreds of millions of PDFs


Of course it will not be impossible to read. But there is a big  
difference between being able to have copies of all published RFCs on  
local storage (another issue with PDF: the files are many orders of  
magnitude larger) that are  searchable with widely available tools  
and having to enlist specialist help to extract the desired information.


I'm convinced that the success of the TCP/IP and web families of  
standards has a great deal to do with the fact that the standards  
documents involved are freely and easily available.


The output of the IETF is simply not that critical for this level  
of concern to be warranted. RFCs are exactly that, requests for  
comment.


Go ask the people at the company you work for how important they  
think their GTLD servers are, and how critical RFCs 791, 768 and 1035  
(to name a few old ones) are for their continued operation.



The real standards are and will always be set by running code.


This is so absurd that I don't even know what to say.

Without continued maintenance the value of standards is quickly  
lost in any case. RFC 822 has long since ceased to be the Internet  
email standard, it is of historic interest only. The same is close  
to being the case for RFC 2822 as well.


That's nice. But I doubt you're going to be able to read that email  
message exchanged through the latest version of the SMTP protocol  
without some support for RFC 894 along the way.


The underlying fallacy here is that the documents are holy  
scriptures, they are not, they are merely an engineering tool to  
effect an engineering outcome.


Talk about what may happen in fifty or a hundred years time is  
simply an ego trip. Its like those folk who in the dotcom boom took  
out million dollar key man insurance. It had nothing to do with the  
damage that might be done to the company if they died unexpectedly  
it was a pure ego trip from start to finish.


It's the other way around. Time and time again, when an engineer  
thought "well, by that time surely the system will be replaced" this  
turned out to be a mistake. Is Y2K really that long ago that we don't  
remember that lesson?


By the way: I happened to see a documentary on sky scrapers on the  
BBC the other night. I was surprised to see that the Woolworth  
building in New York (built in 1913) still has the original elevator  
machinary in operation. It would suck to have to replace a bunch of  
elevators because you don't have the documentation to prove that  
they're still up to code...


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Last call: BCP 47 second part.

[JFC (Jefsey) Morfin]

Dear IESG Members,

1.  The proposed Draft is not about matching (it is absurd to say 
that my Italian can "match" your Japanese in order for us to 
understand each other better). It is about using pattern matching 
techniques in order to filter lists against a langtag with two 
results (max one answer, no max) and in two cases (well formed 
langtag or not). However, the wording is such that without examples 
it is difficult to understand the specifications of the pattern 
matching function that is being used - and therefore the possible 
applications and the purpose of the Draft.  The algorithm of this 
function is undocumented and there is no obligation to document it, 
what may lead to blocking conflicts if two filters may have to 
interoperate. This proposition is NOT scalable and does not intent to 
be scalable.


2. Either RFC 3066 Bis is well written (what I think we achieved if 
strictly limited to the Internationalized ASCII Internet) and well 
applied (what I can see that it is not the case: the review mechanism 
does not respect RFC 3066 Bis) and the filtering is already built-in, 
and the functional strategies are to be specific to applications and 
protocols. Or that Draft, which does not seek to first ensure that 
langtags respect RFC 3066 Bis (i.e. being well formed or corrected in 
order to become well formed), is a negation of RFC 3066 Bis. I think 
that authors had filtering in mind (it was the apex of the first 
unique document) and did not realise that the work achieved in 
cleaning the first part made its correction by the second part not 
necessary anymore. That is if the whole purpose was not a non 
documented use of the filtering (users mass profiling). If it was not 
the whole document can be written as "make sure langtags are well 
formed and feed them on the pattern matching function of your 
application/protocol to obtain the results it needs along your 
language management strategy".


3. "*" restrictions in the pattern matching function can hardly be 
understood without several examples. They add usage limitations to 
the RFC 3066 Bis format, where they should be documented ­ or the 
Draft cannot be part of BCP 47. This certainly belongs to the 
language constraining strategy of the WG-LTRU affinity group and to 
the interests a co-Chair recently documented. But this is 
unacceptable to most users, even if it is certainly favourable to a 
national strategy and to the members of a given consortium. I 
therefore submit that the IESG Members who are citizens of that 
nation, or members, or employees of the members of that commercial 
consortium have a COI.


4. All the above  means that the Draft is useful in at least two circumstances:
  - if the langtags are not well formed or do not respect the 
principles of ISO 639-4 and/or RFC 3066 Bis.
  - if the langtags are used for other purposes that are 
undocumented at the WG-LTRU Charter.

These circumstances should be documented.

5. The security section should mention that this Daft encourages the 
disrespect of the RFC 3066 Bis format and further assists dangerous 
projects that the IETF has refused to mention in RFC 3066 Bis, such 
as lingual, cultural, racial, and religious profiling through 
retro-meta-spam ("I know who you are through which langtags you are 
not aware that you respond to"), two-tier Internet based upon the 
lingual characteristics of the users and their supposed market value, 
lack of conformance to ISO 11179, which may lead the IETF, 
stakeholders, and users to inadequate, costly, and delaying 
strategies or to conflicts with the Multilingual Internet - as in the 
sad DoS against the leading economic language ("en-EU") - or to legal 
access bans by democratic or privacy oriented countries. All of this 
lends itself to incentives for an Internet fragmentation.


6. As far as I understand, two Draft compliant filters may result in 
different responses for the same filtering list and document. My 
concern is the interoperability of the proposed BCP 47 with 
Multilingual Internet registries, tags, etc. This interoperability is 
not ensured ­ and there is no prospect to see it insured as it is 
purposely ignored by authors. This represents no incentive for developers.


7. The acknowledgement section mostly quote those who contributed to 
the pre-WG-LTRU document (the three WG-LTRU Draft existed prior to 
the creation of the WG which never studied and tried to conform to 
its Charter). This is the privilege of authors to quote who supported 
them best. However, in this case the document was considerably 
cleaned through the tough life of the WG. Also, most of the names 
being quoted are widely known as belonging to a non-IETF affinity 
group, what enforces the external understanding that BCP 47 documents 
are actually not IETF documents. This will most probably limit their 
consideration. After one year of tough debates I can testify these, 
good or not, three documents are IETF documents for the 
Internationali

Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Stephane Bortzmeyer]

On Fri, Jun 16, 2006 at 03:46:16PM -0700,
 Joe Touch <[EMAIL PROTECTED]> wrote 
 a message of 85 lines which said:

>   - edit source code (argh - back to the stone age)

I always assumed that most people involved in IETF edit source code
daily (I did not say "full-time", I said "at least daily, or, let's be
gentle, weekly").

Was I wrong?

And editing (in their raw, text-only, form) document formats like
LaTeX or DocBook or HTML or RFC 2629 is much easier than
editing source code.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Julian Reschke]

Peter Dambier schrieb:
>...

Unicode Box Drawing

??
? This is a box  ?
??
?With another box?
?   underneath   ?
??



There were no boxes but a peculiar line below.






...


Well, that indicates that your mail program either didn't understand the 
character encoding, or that the font you are using is missing glyphs for 
some of the Unicode box drawing characters.


As far as I am concerned, at some point the IETF should start on relying 
on some of 1990's technology being present, such as relying on certain 
Unicode code points to be readable by everybody. That being said, at 
least on Win XP the standard fonts seem to support only a subset of the 
 Unicode box drawing characters, which is a shame.


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Hallam-Baker, Phillip]

> From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] 

> It's not _that_ bizarre. Suppose that we decide to allow 
> publishing RFCs in PDF only. Suppose that within the next few 
> years some company comes up with a replacement for PDF that 
> is better is some important regard so that everyone switches 
> to the new format.

And suppose some Vogons came along and demolished the planet to make way for a 
hyperspace bypass.

The idea that any of the formats being discussed will become impossible to read 
is silly. There are billions of HTML document and hundreds of millions of PDFs

The folk at Google, the US Government and pretty much every online library 
project are each going to make sure nothing of the kind happens for far more 
obscure formats.


The output of the IETF is simply not that critical for this level of concern to 
be warranted. RFCs are exactly that, requests for comment. The real standards 
are and will always be set by running code.

Without continued maintenance the value of standards is quickly lost in any 
case. RFC 822 has long since ceased to be the Internet email standard, it is of 
historic interest only. The same is close to being the case for RFC 2822 as 
well. 


The underlying fallacy here is that the documents are holy scriptures, they are 
not, they are merely an engineering tool to effect an engineering outcome. 

Talk about what may happen in fifty or a hundred years time is simply an ego 
trip. Its like those folk who in the dotcom boom took out million dollar key 
man insurance. It had nothing to do with the damage that might be done to the 
company if they died unexpectedly it was a pure ego trip from start to finish. 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Iljitsch van Beijnum]

On 18-jun-2006, at 13:23, Hallam-Baker, Phillip wrote:


Show me a PDF viewer written by a 16-year-old in BASIC, or
whatever it is that bored kids write software in these days.


I am more concerned about making a document readable and  
intelligible by a 16 year old doing a high school class than the  
somewhat bizare notion of them writing text editors for use by  
people writing them.


It's not _that_ bizarre. Suppose that we decide to allow publishing  
RFCs in PDF only. Suppose that within the next few years some company  
comes up with a replacement for PDF that is better is some important  
regard so that everyone switches to the new format. Suppose that a  
decade later, someone wants to read one of those RFCs that is only  
available in PDF. At that point, it will be extremely hard to do  
that, because all the new software doesn't support PDF anymore, or in  
a way that's too limited to be useful. Using old software that with  
good PDF support isn't an option either, because very little software  
still runs after a decade or so of OS updates. And writing a PDF  
viewer just for this isn't really an option either, while writing a  
viewer or even editor that can handle today's RFC format is.



The steps required to format an RFC nicely are far from trivial.


It's simple enough, it just takes a lot of effort without good tools.

But I'm still not sure what problem exactly we're trying to solve.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Peter Dambier]

Clement Cherlin wrote:

On 6/17/06, Eliot Lear <[EMAIL PROTECTED]> wrote:



I do think that ASCII art has its limits, particularly when it comes to
mathematics.  But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all the others Joel raised.

Eliot



I believe one gradual approach that hasn't been discussed is using
Unicode instead of ASCII.  Many of the problems of representing
mathematics and diagrams could be resolved that way, while still
retaining the compatibility and portability advantages of plain text.
The majority of the solutions I've seen proposed would end up using
Unicode as their base character set, so why not cut out the elaborate
markup languages and use Unicode directly?

I just whipped up some sample fixed-width Unicode art, to illustrate
the possibilities:

Unicode Math

   __
-b±?b²-4ac
??
   2a



The Math I could see, except for the divider line, Iguess.



Unicode Box Drawing

??
? This is a box  ?
??
?With another box?
?   underneath   ?
??



There were no boxes but a peculiar line below.








How about Tex?

It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.

ASCII has its limits, yes.

All the alternatives mentioned are even more limited.
Except EBCDIC of course :)

I dont mind getting something new - if somebody else pays for it :)
But I dont like to lose something I need.

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Hallam-Baker, Phillip]

> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] 
> 
> ... and, you've completely missed the point.
> 
> Currently, RFC's are published and distributed in a form 
> which is so straightforward that a child could write software 
> to view or produce it.
> 
> Show me a PDF viewer written by a 16-year-old in BASIC, or 
> whatever it is that bored kids write software in these days.

I am more concerned about making a document readable and intelligible by a 16 
year old doing a high school class than the somewhat bizare notion of them 
writing text editors for use by people writing them.

The steps required to format an RFC nicely are far from trivial. 

I have written ps peresentation software, its essentially the same problem as 
pdf. Its not that much harder to do.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Clement Cherlin]

On 6/17/06, Eliot Lear <[EMAIL PROTECTED]> wrote:


I do think that ASCII art has its limits, particularly when it comes to
mathematics.  But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all the others Joel raised.

Eliot


I believe one gradual approach that hasn't been discussed is using
Unicode instead of ASCII.  Many of the problems of representing
mathematics and diagrams could be resolved that way, while still
retaining the compatibility and portability advantages of plain text.
The majority of the solutions I've seen proposed would end up using
Unicode as their base character set, so why not cut out the elaborate
markup languages and use Unicode directly?

I just whipped up some sample fixed-width Unicode art, to illustrate
the possibilities:

Unicode Math

   __
−b±√b²−4ac
──
   2a


Unicode Box Drawing

┌┐
│ This is a box  │
├┤
│With another box│
│   underneath   │
└┘
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Iljitsch van Beijnum]

On 17-jun-2006, at 16:59, Eliot Lear wrote:

I do think that ASCII art has its limits, particularly when it  
comes to

mathematics.


I'm pretty sure I read as many RFCs as the next IETF participant  
(well, the ones that don't have a three or four letter acronym  
starting with "I" in their job description, anyway) and the only  
formula I seem to remember is this one:


  log(number of allocated objects)
   HD = --
 log(maximum number of allocatable objects)

In other words: is this really a significant issue in practice?

It's much better to use the way this is expressed in well-known  
programming languages anyway, like:


hd = log(numberofallocatedobjects) / log 
(maximumnumberofallocatableobjects)


This also gets around the limitation that exists in math and perl  
where you're lost if you don't know the meaning of a certain symbol  
because you can't easily look up unknown symbols like you can with  
unknown words.


An interesting side-issue is that if RFCs are no longer plain ASCII,  
it gets a lot more difficult to discuss them in email.



But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue  
but

all the others Joel raised.


Looks to me that we don't even agree on what the problem is yet.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf