Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be
allowed.
One requirement/motivation for this change (as set forth in the ID)
is to be able to include drawings and diagrams with something much
more flexible than ASCII art.
Based on the prior discussion of 'ASCII art', and the current
discussion, I see few people arguing that ASCII text is all we need
and that no other formats should ever be allowed.
Let's set aside for now which format(s), and take that as a later
step if we can take this first step.
Splitting the question this way paves the way for those pushing for
alternative formats to frame the next question as, "Which alternative
format are we going to allow?", as if it's already decided that we're
going to allow *some* alternative and just have to find the best, or
at least the least objectionable, even if there aren't any that
fulfill the IETF's overall needs as well as plain ASCII text. If you
add the qualifier, "if they meet our requirements" ("... better than
plain ASCII text"?), then I doubt you'll get much disagreement with
that statement, though you'll probably get a lot of discussion about
how we don't yet *have* a specific list of requirements. As Brian's
brown paper bag note suggests, we should start there, not with the
assumption that we *will* allow some alternate format
Personally, I'm skeptical that we'll find an alternative that meets
our requirements as well, but perhaps we'll wind up with plain UTF-8
text or something.
Ken
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R \\(Jerry\\)" <[EMAIL PROTECTED]> wrote: > Happy New Year to all! > > Many thanks to Yaakov for his excellent handling of the list > discussion. I'm not very surprised with the way it has gone. > Déjà vu all over again :-) > > The challenge is to focus the discussion to try to reach > consensus on moving forward with a process change, i.e., we > need to take baby steps to make progress. > > I'd suggest we try to reach consensus first on the following: > Alternative format(s) for IDs, in addition to ASCII text, > should be allowed. > > One requirement/motivation for this change (as set forth in > the ID) is to be able to include drawings and diagrams with > something much more flexible than ASCII art. > > Based on the prior discussion of 'ASCII art', and the current > discussion, I see few people arguing that ASCII text is all we > need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say "never". > Let's set aside for now which format(s), and take that as a > later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is "good enough" has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. If you do more of it, perhaps we can move some of the interoperability problems into the realm of actual IETF experience and out of the realm of extrapolation from other situations mixed with pure speculation. Free advice: if and when you want to move beyond that point, drop (or isolate into separate documents): (1) Recommendations for IETF process change or specific ways to determine consensus. They should be separate so they can be considered separately, using an appropriate process. (2) Distinguish clearly between what is required or tolerable for I-Ds and what is required or tolerable for RFCs. RFCs, in general, put a less strong requirement on easy extraction and modification of text than I-Ds. And, since I-Ds in theory expire after six months, you might be able to convince the community that the "be sure it can be read twenty years later" requirement for archival documents should not be taken as seriously for I-Ds. (3) Recommendations to permit any format that is (i) proprietary, or (ii) dependent on particular software for processing where that software carries either high costs, onerous licensing requirements, or licensing requirement that attempt to prohibit the development of independent tools to work with the format, or (iii) significantly operating-system dependent, or (iv) significantly version-dependent in the sense that the documents are not forward and backward compatible. I would suggest to you that the fact that Word hits a jackpot by satisfying all of the negative criteria in that third suggestion is the reason why it has been regularly rejected for IETF posting and working use in the past and is almost certain to be rejected in the future. If you want to consider that déjà vu (or deja vu, for ASCII-readers), it certainly is in the sense that we have been here before... but that rather misses the point: it has been rejected in the past for substantial and substantive reasons and the déjà vu situation, for me at least, is that someone decides to bring it up again every few years as if it had never been considered in the past. regards, john _
Re: Baby Steps (was RE: Alternative formats for IDs)
Ken Raeburn wrote:
On Jan 5, 2006, at 09:25, Ash, Gerald R ((Jerry)) wrote:
I'd suggest we try to reach consensus first on the following:
Alternative format(s) for IDs, in addition to ASCII text, should be
allowed.
One requirement/motivation for this change (as set forth in the ID)
is to be able to include drawings and diagrams with something much
more flexible than ASCII art.
Based on the prior discussion of 'ASCII art', and the current
discussion, I see few people arguing that ASCII text is all we need
and that no other formats should ever be allowed.
Let's set aside for now which format(s), and take that as a later
step if we can take this first step.
Splitting the question this way paves the way for those pushing for
alternative formats to frame the next question as, "Which alternative
format are we going to allow?", as if it's already decided that we're
going to allow *some* alternative and just have to find the best, or
at least the least objectionable, even if there aren't any that
fulfill the IETF's overall needs as well as plain ASCII text. If you
add the qualifier, "if they meet our requirements" ("... better than
plain ASCII text"?), then I doubt you'll get much disagreement with
that statement, though you'll probably get a lot of discussion about
how we don't yet *have* a specific list of requirements. As Brian's
brown paper bag note suggests, we should start there, not with the
assumption that we *will* allow some alternate format
Personally, I'm skeptical that we'll find an alternative that meets
our requirements as well, but perhaps we'll wind up with plain UTF-8
text or something.
How would I encode graphics in UTF-8?
Stewart
Ken
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R \\(Jerry\\)" <[EMAIL PROTECTED]> wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say "never". Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is "good enough" has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please clarify this. Are you saying that if the WG/WGchairs/ADs agree that the non-ASCII version should be the normative version (because they want the better artwork), then that's OK? I thought I asked this a long time ago and was told no. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text including graphics will become the RFC? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
On 01/05/2006 11:28 AM, John C Klensin allegedly wrote: > Even those of us who are strongly supportive of ASCII as our > primary base format and those who believe that the effort needed > to simplify illustrations and diagrams sufficiently that they > can be accurately represented in ASCII artwork is helpful in > forcing clarity are reluctant to say "never". > Unless the IESG has changed the rules while I was not looking, > it has been permitted to post I-Ds in PDF in addition to ASCII > for some years. Yes. I support ASCII as the output format. I appreciate the discipline it encourages of separating protocol specification from descriptive text and figures, and of being very clear about state machines, etc. However, there are cases where descriptive text and figures are much more informative in some other format, so I wouldn't say never (nor should I be forced into a position of choosing between never and always). > I find it interesting that it has not been taken > advantage of more often (and, for the record, I'm one of those > who has taken advantage of it). For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. "3" means "draw toward the upper right". swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Scott W Brim wrote: For heuristic value ... Do you think there is a correlation between restricting ourselves to formats which are good for protocol specifications but not much else, and the skew in our success record toward problems solved by protocol specifications as opposed to the really complex system problems? :-) Of course. By the way, I like emacs picture mode. You can bind the keypad keys so that e.g. "3" means "draw toward the upper right". This seems intuituve and easy, if your normal input device is a telephone keypad. Otherwise, why choose this example? -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
> > Unless the IESG has changed the rules while I was not looking, > > it has been permitted to post I-Ds in PDF in addition to ASCII > > for some years. > BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. > Changing that rule alone would be sufficient to allow modern > graphics to be called up in normative texts. Agreed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Jerry, And this is a déjà vu over and over again as well. We could - in theory - allow draft versions in any format an author chooses. It would make quite a mess of the draft repository and - eventually - the RFC library. But we need to agree on one or more versions that can be (more or less) viewed by anyone, if we expect that everyone will actually read and use them. I believe the current practice allows for multiple formats, but requires that at least one is in ASCII text. And, in cases where the document is expected to be of an authoritative nature, the "authoritative version" is the one in the common (ASCII text) format. If that were acceptable to everyone, we could stop there, rather than taking the next "baby step" off the top stair. :-) However, there are a number of people who feel that complex figures are required to understand authoritative text in at least some cases - and this is a good argument for making a version that contains these complex figures authoritative. At this point, all agreement breaks down. The only way to go forward (assuming that change is part of the definition of "going forward") is through arbitration. I am certain that (déjà vu, yet again) arbitration has been tried again and again... -- Eric --> -Original Message- --> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] --> On Behalf Of Ash, Gerald R (Jerry) --> Sent: Thursday, January 05, 2006 9:26 AM --> To: Yaakov Stein; ietf@ietf.org --> Cc: Ash, Gerald R (Jerry) --> Subject: Baby Steps (was RE: Alternative formats for IDs) --> --> Happy New Year to all! --> --> Many thanks to Yaakov for his excellent handling of the --> list discussion. I'm not very surprised with the way it --> has gone. Déjà vu all over again :-) --> --> The challenge is to focus the discussion to try to reach --> consensus on moving forward with a process change, i.e., we --> need to take baby steps to make progress. --> --> I'd suggest we try to reach consensus first on the following: --> Alternative format(s) for IDs, in addition to ASCII text, --> should be allowed. --> --> One requirement/motivation for this change (as set forth in --> the ID) is to be able to include drawings and diagrams with --> something much more flexible than ASCII art. --> --> Based on the prior discussion of 'ASCII art', and the --> current discussion, I see few people arguing that ASCII --> text is all we need and that no other formats should ever --> be allowed. --> --> Let's set aside for now which format(s), and take that as a --> later step if we can take this first step. --> --> Thanks, --> Regards, --> Jerry --> --> --> --> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] --> On Behalf Of Yaakov Stein --> Sent: Sunday, January 01, 2006 12:37 AM --> To: ietf@ietf.org --> Subject: Alternative formats for IDs --> --> Happy new year to everyone. --> --> I would like to call your attention to a new ID --> http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. --> --> This ID is the result of discussions here on the general list, --> and proposes the use of formats other than plain ASCII --> for IDs and RFCs. In particular, it proposes the allowance --> of diagrams other than "ASCII-art" as normative. --> --> The authors felt that further discussion on the list would --> not be productive, --> but that the writing of an ID might force more serious --> consideration. --> We furthermore suggest that this ID be advanced as a BCP --> under the process for process change. --> --> Y(J)S --> --> ___ --> Ietf mailing list --> Ietf@ietf.org --> https://www1.ietf.org/mailman/listinfo/ietf --> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
John, I believe - for the record - that Post-Script is also allowed. -- Eric --> -Original Message- --> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] --> On Behalf Of John C Klensin --> Sent: Thursday, January 05, 2006 11:28 AM --> To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@ietf.org --> Subject: Re: Baby Steps (was RE: Alternative formats for IDs) --> --> --> --> --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R --> \\(Jerry\\)" <[EMAIL PROTECTED]> wrote: --> --> > Happy New Year to all! --> > --> > Many thanks to Yaakov for his excellent handling of the list --> > discussion. I'm not very surprised with the way it has gone. --> > Déjà vu all over again :-) --> > --> > The challenge is to focus the discussion to try to reach --> > consensus on moving forward with a process change, i.e., we --> > need to take baby steps to make progress. --> > --> > I'd suggest we try to reach consensus first on the following: --> > Alternative format(s) for IDs, in addition to ASCII text, --> > should be allowed. --> > --> > One requirement/motivation for this change (as set forth in --> > the ID) is to be able to include drawings and diagrams with --> > something much more flexible than ASCII art. --> > --> > Based on the prior discussion of 'ASCII art', and the current --> > discussion, I see few people arguing that ASCII text is all we --> > need and that no other formats should ever be allowed. --> --> Even those of us who are strongly supportive of ASCII as our --> primary base format and those who believe that the effort needed --> to simplify illustrations and diagrams sufficiently that they --> can be accurately represented in ASCII artwork is helpful in --> forcing clarity are reluctant to say "never". --> --> > Let's set aside for now which format(s), and take that as a --> > later step if we can take this first step. --> --> Jerry, one of the nice things about baby steps is that you --> sometimes discover that the baby learned to take the steps --> without any instruction. --> --> Unless the IESG has changed the rules while I was not looking, --> it has been permitted to post I-Ds in PDF in addition to ASCII --> for some years. I find it interesting that it has not been taken --> advantage of more often (and, for the record, I'm one of those --> who has taken advantage of it). When it has been done for --> artwork purposes, the artwork in the ASCII version has sometimes --> been pretty rudimentary. In practice, whether it is "good --> enough" has been made on a case by case basis by WG Chairs and --> WGs or, for non-WG documents, by whether or not the relevant --> people are willing to read and consider those documents. --> Similarly, when PDF has been posted in order to exhibit --> non-ASCII characters, it has proven helpful to have Unicode --> character offsets (i.e., U+ representations) in both the --> ASCII and PDF forms to ensure complete precision even though the --> character-glyphs themselves appear only in the PDF form. --> --> So, consider the first baby step to have been taken: nothing --> prevents you from posting an I-D in both ASCII and PDF today, --> and the relevant sub-community will sort out, on a case by case --> basis, whether the ASCII is good enough. If you do more of it, --> perhaps we can move some of the interoperability problems into --> the realm of actual IETF experience and out of the realm of --> extrapolation from other situations mixed with pure speculation. --> --> Free advice: if and when you want to move beyond that point, --> drop (or isolate into separate documents): --> --> (1) Recommendations for IETF process change or specific --> ways to determine consensus. They should be separate so --> they can be considered separately, using an appropriate --> process. --> --> (2) Distinguish clearly between what is required or --> tolerable for I-Ds and what is required or tolerable for --> RFCs. RFCs, in general, put a less strong requirement --> on easy extraction and modification of text than I-Ds. --> And, since I-Ds in theory expire after six months, you --> might be able to convince the community that the "be --> sure it can be read twenty years later" requirement for --> archival documents should not be taken as seriously for --> I-Ds. --> --> (3) Recommendations to permit any format that is (i) --> proprietary, or (ii) dependent on particular software --> for processing where that software carries either high --> co
RE: Baby Steps (was RE: Alternative formats for IDs)
Stewart,
You bring up a good point. I have been assuming that - since
IDs can be submitted in multiple formats - that the additional
formats would also become part of the RFC library on publication.
I just took a quick peek at the RFCs and there does not appear
to be a single example of a version that is not in text format. I
don't know if that is because they are not stored in the same place,
or they are not carried forward as part of the publishing process.
Frankly, if the process of getting an ID published as an RFC
seems to require (or at least encourage) use of at least one
additional format, then the additional format(s) should also be
incorporated in the RFC library. In other words, if there was a
non-ASCII version of the ID, there should also be a non-ASCII
version of the RFC.
For some reason I thought this at least used to be the case.
If it is not, then that should be fixed - for exactly the reasons
you point out.
Irrespective of questions about the "legitimacy" of using a
non-ASCII version as normative or authoritative, the fact that a
non-ASCII version might contain useful explanatory material is
more than sufficient cause to keep it.
--
Eric
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Stewart Bryant
Sent: Thursday, January 05, 2006 12:01 PM
To: John C Klensin
Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org
Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
John C Klensin wrote:
--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>
wrote:
Happy New Year to all!
Many thanks to Yaakov for his excellent handling of
the list
discussion. I'm not very surprised with the way it
has gone.
Déjà vu all over again :-)
The challenge is to focus the discussion to try to
reach
consensus on moving forward with a process change,
i.e., we
need to take baby steps to make progress.
I'd suggest we try to reach consensus first on the
following:
Alternative format(s) for IDs, in addition to ASCII
text,
should be allowed.
One requirement/motivation for this change (as set
forth in
the ID) is to be able to include drawings and
diagrams with
something much more flexible than ASCII art.
Based on the prior discussion of 'ASCII art', and
the current
discussion, I see few people arguing that ASCII text
is all we
need and that no other formats should ever be
allowed.
Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort
needed
to simplify illustrations and diagrams sufficiently that
they
can be accurately represented in ASCII artwork is helpful in
forcing clarity are reluctant to say "never".
Let's set aside for now which format(s), and take
that as a
later step if we can take this first step.
Jerry, one of the nice things about baby steps is that you
sometimes discover that the baby learned to take the steps
without any instruction.
Unless the IESG has changed the rules while I was not
looking,
it has been permitted to post I-Ds in PDF in addition to
ASCII
for some years.
BUT the pdf is not allowed to be normative. Changing that rule alone
would
be sufficient to allow modern graphics to be called up in normative
texts.
I find it interesting that it has not been taken
advantage of more often (and, for the record, I'm one of
those
who has taken advantage of it). When it has been done for
artwork purposes, the artwork in the ASCII version has
sometimes
been pretty rudimentary. In practice, whether it is "good
enough" has been made on a case by case basis by WG Chairs
and
WGs or, for non-WG documents, by whether or n
Re: Baby Steps (was RE: Alternative formats for IDs)
On Jan 5, 2006, at 11:49, Stewart Bryant wrote: Ken Raeburn wrote: Personally, I'm skeptical that we'll find an alternative that meets our requirements as well, but perhaps we'll wind up with plain UTF-8 text or something. How would I encode graphics in UTF-8? Same as you do in ASCII now (i.e., poorly), but you get a few more characters to choose from. :-) Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
--On Thursday, 05 January, 2006 13:17 -0500 "Gray, Eric" <[EMAIL PROTECTED]> wrote: > Stewart, > > You bring up a good point. I have been assuming that - > since IDs can be submitted in multiple formats - that the > additional formats would also become part of the RFC library > on publication. > I just took a quick peek at the RFCs and there does not > appear to be a single example of a version that is not in > text format. I don't know if that is because they are not > stored in the same place, or they are not carried forward as > part of the publishing process. >... The number is not huge, but some RFCs have, in fact, been published formally in PS and/or PDF as well as in ASCII (and I'm on the hook for another one... something else in a too-long queue). See RFC 3550 and 3551 for recent standards-track examples and RFC 1119 for an a Full Standard example that is legendary in some parts of the community for incomprehensibility if one has only the ASCII text and diagrams. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Gray, Eric wrote: Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. You must have looked in the wrong place. Where there are PS or PDF versions, they can be found via the search page at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl It's less clear that all mirror sites carry them. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Ash, Gerald R (Jerry) wrote: Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. It would, and the same would apply to mathematical formulae. As a matter of fact, the relatively unmodern RFC 1119 that John mentioned does use some graphics and mathematics that would be annoying to code in ASCII. We can certainly ask the question whether that is a big enough benefit to be worth the cost. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
*> > *> > I just took a quick peek at the RFCs and there does not appear *> > to be a single example of a version that is not in text format. I *> > don't know if that is because they are not stored in the same place, *> > or they are not carried forward as part of the publishing process. *> You must not be looking at the official RFC repository maintained by the RFC Editor. For Unix fans, looking at the ~in-notes directory: 31% ls -al rfc*.ps|wc 55 4403127 32% ls -al rfc*.pdf|wc 54 4323124 That is, there are 55 Postscript RFCs and 54 PDF RFCs (they don't exactly match because some early Postscript files could not be converted to PDF). Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Permitting PDF and Postscript (was: RE: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 05 January, 2006 12:46 -0500 "Gray, Eric" <[EMAIL PROTECTED]> wrote: > John, > > I believe - for the record - that Post-Script is also > allowed. It is indeed. And it, as well as PDF, are allowed in RFCs (see earlier note). As others have noted, an ASCII form is still required. I consider that a feature and, for various worst cases, futureproofing, but some others do not. And, as yet others have noted, it would be wise for us to get very specific about versioning and permitted feature-sets for PDF. It is arguably even more important to get specific about versions and feature sets for PS although my own personal opinion is that, given PDF, Postscript has about outlived its usefulness as a separate posting format. YMMD, of course, and this thread on the IETF list is probably not the optimal way to address that question in any event. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 05 January, 2006 17:01 + Stewart Bryant <[EMAIL PROTECTED]> wrote: >... >> I find it interesting that it has not been taken >> advantage of more often (and, for the record, I'm one of those >> who has taken advantage of it). When it has been done for >> artwork purposes, the artwork in the ASCII version has >> sometimes been pretty rudimentary. In practice, whether it >> is "good enough" has been made on a case by case basis by WG >> Chairs and WGs or, for non-WG documents, by whether or not >> the relevant people are willing to read and consider those >> documents. > Please clarify this. Are you saying that if the > WG/WGchairs/ADs agree that the non-ASCII > version should be the normative version (because they want the > better artwork), then that's > OK? I thought I asked this a long time ago and was told no. No, I'm not saying that. But the distinction I was trying to make is pretty subtle. The ASCII is the ASCII. "Normative" doesn't mean much for an I-D (see below for RFCs). The rule about PDF or Postscript versions is that they are supposed to be equivalent to the ASCII (and vice versa). But "equivalent" gets a little subjective... We know perfectly well that there are a few cases in which, no matter what one does with ASCII art, it is not sufficient to make whatever point is being made and supplemental text --more description, in words, of what would be in the pictures-- will not help much either. Now, part of the point that the people who have said "if you can't do it in ASCII art, you generally shouldn't be doing it -- use the ASCII art and write a better description" are making is that the cases in which we really need fancy pictures are very few and that, except for those cases, we are better off without them or at least being able to treat them as strictly supplementary. Before I go on, I continue to be fascinated by the observation that, each time the "we really need pictures and fancy formatting and need them frequently" argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. Now, of course, some of them might argue that our current rules prevent them from contributing and that, if only we would let them submit documents written with the DeathRay word processor in Klingon script, not only would their productivity rise, but everyone else's would too --once we bought copies of DeathRay, learned Klingon, and persuaded UTC to get the characters into Unicode. However, that aside, assume that you are describing the new Mona Lisa protocol, and that it is really impossible to adequately describe the protocol without a high-resolution scale picture of the Mona Lisa overlaid with your coordinate system. The ASCII form of your document could (and must under our current rules) describe the coordinate system, include all of the measurements, and describe what you are doing with them. That text is normative (and the important thing is "the text", not whether it is in ASCII or not) and has to be. But it is going to be _very_ hard for anyone to understand your protocol without seeing the picture unless they have a good mental image of it. Under those conditions, our precedents are that you can probably convince the WG/WGchairs/ADs, and eventually the RFC Editor, that a PDF document containing a picture of the Mona Lisa and an ASCII document with _- / \ _ | o o | | | | | __ | _ | | \_/ _ | | | | as a substitute for that picture, with the marginal lines roughly identifying your grid marks and coordinate system, is "equivalent" or as close to it as one can get. I would expect that to be a hard sell. I, personally, would _want_ it to be a hard sell. If it is really necessary, folks will figure out how to get the picture (maybe only the picture, which will probably not change from one version of the I-D to the next) to those who can't handle the PDF (or Postscript). But we have done it before, all of the needed rules and procedures are in place, and nothing new is needed other than your understanding that you are going to have to get consensus that the artwork is vital before making that great a departure between the ASCII and the PDF versions. >> Similarly, when PDF has been posted in order to exhibit >> non-ASCII characters, it has proven helpful to have Unicode >> character offsets (i.e., U+ representations) in both the >> ASCII and PDF forms to ensure complete precision even though >> the character-glyphs themselves appear only in the PDF form. >> >> So, consider the first baby step to have been taken: nothing >> prevents you from posting an I-D in both ASCII and PDF today, >> and the relevant sub-community will sort out, on a case by >> case basis, whether the ASCII is good enou
Re: Permitting PDF and Postscript (was: RE: Baby Steps (was RE: Alternative formats for IDs))
In message <[EMAIL PROTECTED]>, John C Klensin writes: > > >--On Thursday, 05 January, 2006 12:46 -0500 "Gray, Eric" ><[EMAIL PROTECTED]> wrote: > >> John, >> >> I believe - for the record - that Post-Script is also >> allowed. > >It is indeed. And it, as well as PDF, are allowed in RFCs (see >earlier note). > >As others have noted, an ASCII form is still required. I >consider that a feature and, for various worst cases, >futureproofing, but some others do not. > >And, as yet others have noted, it would be wise for us to get >very specific about versioning and permitted feature-sets for >PDF. It is arguably even more important to get specific about >versions and feature sets for PS although my own personal >opinion is that, given PDF, Postscript has about outlived its >usefulness as a separate posting format. YMMD, of course, and >this thread on the IETF list is probably not the optimal way to >address that question in any event. > Producing good, portable PDF isn't obvious. I just added the following text to a Call for Papers of a conference I'm chairing, based on many sad experiences trying to read random PDF files submitted by others: PDF users should use "Type 1" fonts instead of "Type 3", and should "Embed" and "Subset" all fonts. You can find instructions on how to do this at https://www.fastlane.nsf.gov/documents/pdf_create/pdfcreate_01.jsp and http://ismir2005.ismir.net/pdf.html Among the problems I've encountered have been version skew, missing fonts (especially Asian language fonts that are frequently not installed elsewhere), fuzzy text from LaTeX users who are generating bitmap fonts, ligatures getting changed into weird characters, and more. When I sent the PDF for the second edition of my book to the publisher, I had to use these options to dvips: -P pdf -G0 and -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 -dSubsetFonts=true -dEmbedAllFonts=true for ps2pdf. (I've left out the resolution.) I should note that it didn't work, either -- but if I sent them the PS, they could convert it to PDF. We never did figure out that problem --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
*> *> Under those conditions, our precedents are that you can probably *> convince the WG/WGchairs/ADs, and eventually the RFC Editor, *> that a PDF document containing a picture of the Mona Lisa and an *> ASCII document with *> *> _- *> / \ *> _ | o o | *> | | | *> | __ | *> _ | | *> \_/ *> _ *> | | | | *> *> as a substitute for that picture, with the marginal lines *> roughly identifying your grid marks and coordinate system, is *> "equivalent" or as close to it as one can get. John, AFAIK, there is one worked example of this ... RFC 1119 on NTP. Philosophers may speculate on the resemblance of NTP to the Mona Lisa... Bob Braden *> *> *> ___ *> Ietf mailing list *> Ietf@ietf.org *> https://www1.ietf.org/mailman/listinfo/ietf *> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
> Before I go on, I continue to be fascinated by the observation > that, each time the "we really need pictures and fancy > formatting and need them frequently" argument comes up, the vast > majority of those who make it most strongly are people whose > contributions to the IETF -- in designer, editor, or other > leadership roles-- have been fairly minimal. This fascinates me too... With experience, I believe most people learn that the strict ASCII format used for RFC's is actually a strong feature of our ways of working. When I wrote my first drafts, I also believed non-ASCII graphics were needed and I made multiple versions (one TXT and one PS) of each draft, but I do not waste my time on that anymore since I have learned that I can manage very well without non-ASCII graphics. /L-E ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
Lars-Erik Jonsson (LU/EAB) wrote: Before I go on, I continue to be fascinated by the observation that, each time the "we really need pictures and fancy formatting and need them frequently" argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. This fascinates me too... That is a completly inapproriate response to the issue at hand - in many dimensions. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
--On Thursday, 12 January, 2006 12:28 +0100 "Lars-Erik Jonsson \\(LU/EAB\\)" <[EMAIL PROTECTED]> wrote: >> Before I go on, I continue to be fascinated by the observation >> that, each time the "we really need pictures and fancy >> formatting and need them frequently" argument comes up, the >> vast majority of those who make it most strongly are people >> whose contributions to the IETF -- in designer, editor, or >> other leadership roles-- have been fairly minimal. > > This fascinates me too... > > With experience, I believe most people learn that the strict > ASCII format used for RFC's is actually a strong feature of > our ways of working. When I wrote my first drafts, I also > believed non-ASCII graphics were needed and I made multiple > versions (one TXT and one PS) of each draft, but I do not > waste my time on that anymore since I have learned that I > can manage very well without non-ASCII graphics. While I agree with you, I should stress that the authors of the current proposal have been much more in touch with IETF work and much more active than many of their predecessors. We also owe them thanks for actually preparing a proposal in I-D form rather than simply complaining about our antiquated methods on the mailing list. Most of the point I was trying to make was precisely the one you make, more appropriately, above: increasing experience within the IETF and with our style of developing and working on documents (not just publishing them) tends to cause both patience and respect for the ASCII graphics and formats to rise. Experience from other standards bodies or similar entities that work in different ways may or may not be a good basis for inference. best, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
On 1/12/06, John C Klensin <[EMAIL PROTECTED]> wrote: > > increasing experience within the IETF and with our style of > developing and working on documents (not just publishing them) > tends to cause both patience and respect for the ASCII graphics > and formats to rise. I'm surprised folks are apologizing for the initial impression ASCII text gives, and that people feel MS Word or PDF would represent some sort of advance. I find both of those formats difficult to use, and my reaction when I see a spec in PDF or MS Word is to assume the responsible organization is clueless. The rare specification requiring elaborate illustrations would be better as HTML with a liberal sprinkling of fragment identifiers. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs))
John, Stewart and others, I believe some might have taken my previous note more personally than intended, as well as John's. As also made clear by John below, we both looked at this with a significantly longer time-perspective than just the last weeks or months, as these issues have been brought up many times before. I am sorry if someone felt insulted, that was for sure not the intent. It is good that we now have discussions trying to figure out actual cases when more graphics are *really* needed, then we might actually get out of these discussions with some new conclusions and agreements that can guide us on the way forward. Cheers, /L-E Original Message From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: den 12 januari 2006 17:41 To: Lars-Erik Jonsson (LU/EAB); Stewart Bryant Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org Subject: RE: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)) > --On Thursday, 12 January, 2006 12:28 +0100 "Lars-Erik Jonsson > \\(LU/EAB\\)" <[EMAIL PROTECTED]> wrote: > >>> Before I go on, I continue to be fascinated by the observation >>> that, each time the "we really need pictures and fancy >>> formatting and need them frequently" argument comes up, the >>> vast majority of those who make it most strongly are people >>> whose contributions to the IETF -- in designer, editor, or >>> other leadership roles-- have been fairly minimal. >> >> This fascinates me too... >> >> With experience, I believe most people learn that the strict >> ASCII format used for RFC's is actually a strong feature of >> our ways of working. When I wrote my first drafts, I also >> believed non-ASCII graphics were needed and I made multiple >> versions (one TXT and one PS) of each draft, but I do not >> waste my time on that anymore since I have learned that I >> can manage very well without non-ASCII graphics. > > While I agree with you, I should stress that the authors of the > current proposal have been much more in touch with IETF work and > much more active than many of their predecessors. We also owe > them thanks for actually preparing a proposal in I-D form rather > than simply complaining about our antiquated methods on the > mailing list. Most of the point I was trying to make was > precisely the one you make, more appropriately, above: > increasing experience within the IETF and with our style of > developing and working on documents (not just publishing them) > tends to cause both patience and respect for the ASCII graphics > and formats to rise. Experience from other standards bodies or > similar entities that work in different ways may or may not be a good > basis for inference. > > best, >john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ancients-moderns dispute (was: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
We need to get out this ancients vs moderns dispute. Ancients saying they have no experience of actual need by moderns, and moderns saying this is because the ancient culture does not permit it. Is there an objection to quote non-ascii documents hyperlinks? I suppose not. Why not to just to proceed step by step and experiment? Let create an optional non-ascii art RFC-Editor repositories, for images quoted in RFCs. This will not permit non-ASCII art to be normative but will permit non-ASCII art to be _better_ descriptive in a first time. Experience will show if there are many such images. If there is a real need for normative non-ASCII art, it will provide experience to create a non-ASCII art IANA registry making sure they will survive, at an adeqate place. jfc At 21:00 05/01/2006, John C Klensin wrote: No, I'm not saying that. But the distinction I was trying to make is pretty subtle. The ASCII is the ASCII. "Normative" doesn't mean much for an I-D (see below for RFCs). The rule about PDF or Postscript versions is that they are supposed to be equivalent to the ASCII (and vice versa). But "equivalent" gets a little subjective... We know perfectly well that there are a few cases in which, no matter what one does with ASCII art, it is not sufficient to make whatever point is being made and supplemental text --more description, in words, of what would be in the pictures-- will not help much either. Now, part of the point that the people who have said "if you can't do it in ASCII art, you generally shouldn't be doing it -- use the ASCII art and write a better description" are making is that the cases in which we really need fancy pictures are very few and that, except for those cases, we are better off without them or at least being able to treat them as strictly supplementary. Before I go on, I continue to be fascinated by the observation that, each time the "we really need pictures and fancy formatting and need them frequently" argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. Now, of course, some of them might argue that our current rules prevent them from contributing and that, if only we would let them submit documents written with the DeathRay word processor in Klingon script, not only would their productivity rise, but everyone else's would too --once we bought copies of DeathRay, learned Klingon, and persuaded UTC to get the characters into Unicode. However, that aside, assume that you are describing the new Mona Lisa protocol, and that it is really impossible to adequately describe the protocol without a high-resolution scale picture of the Mona Lisa overlaid with your coordinate system. The ASCII form of your document could (and must under our current rules) describe the coordinate system, include all of the measurements, and describe what you are doing with them. That text is normative (and the important thing is "the text", not whether it is in ASCII or not) and has to be. But it is going to be _very_ hard for anyone to understand your protocol without seeing the picture unless they have a good mental image of it. Under those conditions, our precedents are that you can probably convince the WG/WGchairs/ADs, and eventually the RFC Editor, that a PDF document containing a picture of the Mona Lisa and an ASCII document with _- / \ _ | o o | | | | | __ | _ | | \_/ _ | | | | as a substitute for that picture, with the marginal lines roughly identifying your grid marks and coordinate system, is "equivalent" or as close to it as one can get. I would expect that to be a hard sell. I, personally, would _want_ it to be a hard sell. If it is really necessary, folks will figure out how to get the picture (maybe only the picture, which will probably not change from one version of the I-D to the next) to those who can't handle the PDF (or Postscript). But we have done it before, all of the needed rules and procedures are in place, and nothing new is needed other than your understanding that you are going to have to get consensus that the artwork is vital before making that great a departure between the ASCII and the PDF versions. >> Similarly, when PDF has been posted in order to exhibit >> non-ASCII characters, it has proven helpful to have Unicode >> character offsets (i.e., U+ representations) in both the >> ASCII and PDF forms to ensure complete precision even though >> the character-glyphs themselves appear only in the PDF form. >> >> So, consider the first baby step to have been taken: nothing >> prevents you from posting an I-D in both ASCII and PDF today, >> and the relevant sub-community will sort out, on a case by >> case basis, whether the ASCII is good enough. >> > ...and if it's not th
Re: ancients-moderns dispute (was: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
*> *> Why not to just to proceed step by step and experiment? Let create an *> optional non-ascii art RFC-Editor repositories, for images quoted in *> RFCs. This will not permit non-ASCII art to be normative but will *> permit non-ASCII art to be _better_ descriptive in a first time. *> Experience will show if there are many such images. If there is a *> real need for normative non-ASCII art, it will provide experience to *> create a non-ASCII art IANA registry making sure they will survive, *> at an adeqate place. *> *> jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ancients-moderns dispute (was: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
At 18:49 06/01/2006, Bob Braden wrote: *> *> Why not to just to proceed step by step and experiment? Let create an *> optional non-ascii art RFC-Editor repositories, for images quoted in *> RFCs. This will not permit non-ASCII art to be normative but will *> permit non-ASCII art to be _better_ descriptive in a first time. *> Experience will show if there are many such images. If there is a *> real need for normative non-ASCII art, it will provide experience to *> create a non-ASCII art IANA registry making sure they will survive, *> at an adeqate place. *> *> jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? I am not suggesting a repository of the RFC PDF version. But a repository of the _art_ attached to an ASCII version. So we first see if there is a real need through the usage made. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
