On 5 jul 2009, at 15:04, Yaakov Stein wrote:
Last but not least, just filter out anything between < and > and
replace a few &xxx; sequences and you're back to plain text. We could
probably even format RFCs such that if you remove the HTML, you're
left with the current ASCII format.
You seemed to have missed the point.
Almost all RFCs have ASCII art in them,
[...]
When you improperly break lines these figures are irreversibly
corrupted,
and in essence you lose a large part of the document.
No, you're missing my point. That point is that a file like this:
<p>In order to be able to use the largest packet sizes under the widest
range of circumstances, nodes SHOULD include a new MTU option in both
neighbor solicitation and neighbor advertisement messages RFC2461".</p>
<p>The format of the neighbor discovery MTU option is as follows:</p>
<pre>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R|T| Transport flags | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
Will display as follows if you remove everything between < and >
(inclusive):
In order to be able to use the largest packet sizes under the widest
range of circumstances, nodes SHOULD include a new MTU option in both
neighbor solicitation and neighbor advertisement messages RFC2461"
The format of the neighbor discovery MTU option is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R|T| Transport flags | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here are links to the examples in case they get lost in the mail:
http://www.bgpexpert.com/drafthtml.txt
http://www.bgpexpert.com/drafthtml.html
http://www.bgpexpert.com/drafthtmlfiltered.txt
So if you object to using a non-ASCII format because it will not be
100% readable 30 years from now, you should object to using the
present format today.
Wasn't that what I was doing?
On 5 jul 2009, at 15:12, Yaakov Stein wrote:
I personally started writing up a description of a packet loss
concealment technique,
but had to give up due to the formulas not being transcribable
(I had no problem submitting a patent application instead).
In TICTOC we are not even considering attempting any work that needs
math,
but rather leave it to other SDOs.
It is considered a limitation of the system.
So once those standards are published somehwere else, what kind of
language do you use to implement them that allows mathematical
formulas to be part of the code?
In other words: anything that can be expressed in math symbols can
also expressed in ASCII, programmers have been doing that for half a
century. Annyoing, but it does have the advantage that once you have
it in that format you don't have to worry about strange
incompatibilities that make the symbols come out wrong.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf