RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose dExperiment: Normative Format in Addition to ASCII Text' toExperimental RFC (draft-ash-alt-formats))
Yaakov, The very next paragraph that follows the one that you are quoting from RFC 3935 talks about the cardinal principles that the IETF is undertaking in order to fulfill its mission. The first principle in the list is Open Process. My interpretation is that while creating tools for tools seek is not part of the mission, sometimes there is a need to do it in order to allow the IETF to stand by its principles and operate in an efficient manner. Dan > -Original Message- > From: Yaakov Stein [mailto:[EMAIL PROTECTED] ... > > When are we going to get back to work relevant to the IETF? > > RFC 3935 is effectively a charter for the IETF as a whole. > It states > >The mission of the IETF is to produce high quality, relevant >technical and engineering documents that influence the way people >design, use, and manage the Internet in such a way as to make the >Internet work better. These documents include protocol standards, >best current practices, and informational documents of > various kinds. > > I believe that some people are mis-interpreting this statement. > > I propose adding as explicit non-goals > * the developing of new document creation tools > * the developing of new version tracking tools > * the development of new document archival processes > > 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: 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))
On 21-jun-2006, at 9:25, Yaakov Stein wrote: And although (as mentioned often before) I am no great fan of Word, I have never seen S/N problems of the type you mention. I suspect that your co-authors are really fooling around way too much with presentation aspects rather than content. ++ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDs first? RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Hallam-Baker, Phillip wrote: The format is straight mime with one added feature, a content header to specify the url of the segment so that links in the document can be disambiguated. It should be an rfc, just need someone to get round to writing it up. I may do that soon because I am looking into using mhtml as an archival format for notarized versions of html documents. if you write it up, make sure you obsolete RFC 2557 (PS since 1999). No reason to have two specs for it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDs first? RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
On Wed Jun 21 00:36:26 2006, Keith Moore wrote: As someone who has actually tried producing I-Ds in alternate formats, I'm not sure that I agree that there's much benefit to having only I-Ds use the new format. People who review the document need to be able to see something close to the version that will actually be published. I would find it interesting if the I-Ds were at least available in their source format as well as their TXT format, though, especially if that was xml2rfc, and it's certainly a more practical zone for experiments about formats than the RFC series itself. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Chair tasks
John C Klensin wrote: --On Monday, 19 June, 2006 10:49 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote: Hi, I'd be interested to know if anyone has comments on draft-carpenter-ietf-chair-tasks-00.txt: This document describes tasks performed by the IETF Chair, the IESG Chair, and the Area Director of the General Area of the IETF. Its purpose is to inform the community of what these tasks are, and to allow the community to consider whether combining all these roles in one person is optimal. In particular, with the new NomCom cycle starting soon, does anyone believe we should discuss the last point? Brian, I don't know if this is just my idiosyncrasies or if others might agree, but let me try to explain why I haven't responded to this note and won't do so before Montreal. I have discovered, reluctantly, that there are only a finite number of hours in a given week, This is a point on which the draft and its author are in violent agreement with you :-) As far as this one is concerned, I have read it a couple of times. Parts of your model of the roles and how they might plausibly be divided are inconsistent with my perceptions. Understood, but as far as what tasks the I* Chair performs today (and has done for at least the last few years), the draft is description, not opinion. Of course, the way tasks are assigned to the differing roles is a matter of judgement and opinion. My sense is that some of the issues could be addressed in radically different ways, ones that might actually work better and, along some dimensions, require fewer changes. That doesn't mean you are wrong. It means that the topics need, IMO, further discussion and presentation and exploration of alternatives. That is certainly true. If the IETF Chair position were up for review by this coming Nomcom, It is. I started my term in March 2005. Time flies. I think I'd take your notes as part of a suggestion to the Nomcom that they solicit from potential candidates, not an ever-longer questionnaire, but an essay that specifically addresses these issues, possibly with the intention of compiling the results and getting them to the community and IESG as part of the decision process. I certainly have it in mind to draw NomCom's attention to the draft. It's up to them what use they choose to make of it. I could elaborate on that idea if anyone cared, but I presume we have a year before it is in the critical path. (Un)fortunately not. Perhaps I should suggest what I would suggest if a participant in the community who was not IETF Chair or on the IESG floated a document like this on an individual basis: Announce a beer BOF schedule for Montreal. Offer, if necessary, to buy the first round or a beer for anyone who makes a constructive suggestion. And then see if, with appropriate lubrication, you get some good input or if anyone cares about the subject matter more than the beer itself. I'm not completely convinced that beer is the appropriate choice in Montreal, but I would definitely welcome informal discussion, because I believe the community does need to face these issues. I fully appreciate your comments (that I have snipped out) about excessive process related discussions, but we need to ensure that future NomComs have viable choices. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDs first? RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
> From: Keith Moore [mailto:[EMAIL PROTECTED] >> Creating one of these archives is easy, just view the HTML page and > click 'save as archive'. > > My copy of firefox doesn't seem to have that feature. Maybe you need to include the archive extension: http://maf.mozdev.org. When I do I get three options: MAF archive, MAF ZIP archive and MAF MHT archive. On Windows, if I save it in Firefox as an MHT archive, then doubleclick on it, it opens apparently correctly in Internet Explorer. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IDs first? RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
Creating one of these archives is easy, just view the HTML page and click 'save as archive'. My copy of firefox doesn't seem to have that feature. Maybe you need to include the archive extension: http://maf.mozdev.org. apparently it's not supported on macs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Profiling PDF for draft-ash-alt-formats
I've been looking at PDF/A. Ghostscript 8.55 (not yet released) supports PDF/A-1b output, and I understand that Adobe Distiller does too, both as an output form and as a preflight check for conformance. I'm inclined to suggest that the document include something like this: PDF files to be published in this experiment are to be limited to the PDF/A-1 profile. PDF/A, also known as ISO 19005, is a profile of PDF designed for long-term archival storage. At the time of this writing, PDF/A-1 (ISO 19005-1:2005) is the current standard, based upon PDF 1.4, while PDF/A-2 is under development, based upon PDF 1.6. PDF/A-1 has two profiles, PDF/A-1a and PDF/A-1b. While -1a is preferable, it places requirements on generating software that may not be easily met, so -1b is permissible. Among other restrictions, PDF/A-1 removes PDF's ability to transport executable code, including Postscript and JavaScript. We place an additional restriction on the form of the file. The text portions of the document must be represented as text in the PDF file, not images of text. PDF/A-1 already disallows encryption, which is the basis of restricting text extraction or searching. The combination of these restrictions ensures that the resulting file will be searchable and the text can be extracted. Any thoughts? I believe the tools to ensure this are easily available - e.g., use ghostscript to make sure the fonts are embedded, and email the PDF to [EMAIL PROTECTED] and make sure that the text that comes back is mostly the same as the ASCII version. Thanks, Bill ___ 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 ASCIIText' to Experimental RFC (draft-ash-alt-formats))
[YJS] My experience has been quite different. I work, on a daily basis, with many extremely complex Word documents each of which is handled by many different people (often with conflicting aims). These documents often go through dozens of revisions. And although (as mentioned often before) I am no great fan of Word, I have never seen S/N problems of the type you mention. I suspect that your co-authors are really fooling around way too much with presentation aspects rather than content. Next time agree on a ground rule that first the ideas should be gotten right, and leave the pretty-printing for the final round. Not only does this make sense and save everyones time, it will probably eliminate your S/N problem. Y(J)S Another apporach that works well is to create an agreed-upon template at the start of the project that is used for the duration. This also provides consistency throughout the documentation, and takes out the S/N error problems. Both OpenOffice and Word make it very easy to create and save a template. Any formatting that is needed beyond what's provided in the template is saved for the final draft. Diana ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-IAB-rfc-editor-00: IAB Charter and IAB
Hi. I sent in some comments a while back and they sparked a lively discussion. However I don't think I made the point I was trying to make successfully and think because of lack of clarity on my part my point came out much more controversial than I had hoped. So, here's try #2. First, I understand there is a consensus that some rfc-editor streams are broader than the IETF and that we need to get community review broader than the IETF when making decisions about those streams. That seems fine to me; I personally think in practice it will be rare that the IETF and this broader community will disagree, but I understand the concern. I'm not trying to object to that. I caution the IAB to make sure that it does not get deadlocked trying to find out how to approach this broader community. It would be unfortunate if in an attempt to get broad review we got no review at all or review by a very small community. I think that is a real concern, but one the IAB is well equipped to handle. I also understand there is a long recorded history of interactions with the RFC editor. (There is an even longer oral tradition, but I trust that we all see the undesirability of making governance decisions about a million dollar/year organization based on oral tradition.) We need to respect that history. We also need to realize that one of the explicit goals of the adminrest process is to formalize and clarify relationships and avoid the need for us to consult this history to find out how things work. Quoting section 3.1.3 of RFC 3716: However, the very clear requirement is for clarity in the distribution of rights, responsibilities, and accountability in those relationships. The usual mechanism for documenting such clarity is in contract form. Thus, the IETF needs to have clear contractual relationships with the organizations supporting basic services, including meeting organization, secretarial services, IT services, etc. The current effort to clarify the relationship with the rfc-editor fits well within that goal. However there are two important ways in which we have already finished the process of clarifying roles and responsibilities. First, we need look only as far as RFC 2850 to find the IAB's role in managing the RFC editor: (d) RFC Series and IANA The RFC Editor executes editorial management and publication of the IETF "Request for Comment" (RFC) document series, which is the permanent document repository of the IETF. The RFC series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. Second, we need only look to RFC 4071 to find IASA's role in the administrative and budget aspects of the RFC editor: The IETF Administrative Support Activity (IASA) provides the administrative structure required to support the IETF standards process and to support the IETF's technical activities. As of the time at which this document was written, this included the work of IETF working groups, the IESG, the IAB, and the IRTF. Should the IETF standards process at some future date come to include other technical activities, the IAOC is responsible for developing plans to provide administrative support for them. Such support includes, as appropriate, undertaking or contracting for the work described in [RFC3716], including IETF document and data management, IETF meetings, and any operational agreements or contracts with the RFC Editor and the Internet Assigned Numbers Authority (IANA). The IASA is also ultimately responsible for the financial activities RFC 4071 makes it clear that the IAOC is charged with preparing a budget that meets the IETF community's administrative needs; it is clear that the IASA is responsible for evaluating each function and making sure that it meets a legitimate IETF administrative need. It would be inappropriate for the IASA to fund a function that did not fill such a role. Just as the ISOC board of directors has reviewed the rfc editor function in detail to confirm that money was being spent in accordance with ISOC's charitable mission, IAOC can and should review the rfc-editor function to make sure that it is meeting the IETF's administrative needs. Why do I mention these two areas where we have already clarified roles and responsibilities? Well, I think the document does not accurately reflect these clarifications in the following ways. First, there is a duality associated with formally granting the IAB authority through a charter: that authority can be r
