Re: Why the normative form of IETF Standards is ASCII
On Wed, Mar 24, 2010 at 11:56 PM, Stefan Santesson ste...@aaa-sec.com wrote: One minor question. How do you use xml2rfc to edit a document when you don't have that document in xml format? I've had luck with converting using xml2rfc-xxe (http://xml2rfc-xxe.googlecode.com/); you select the entire document, use paste as paragraphs to get it into xxe, and insert sections / reflow paragraphs / etc. as needed. Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [xml2rfc] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem
On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier rpellet...@isoc.org wrote: Please advise if there are other questions. Section 6 requires that the text be included on the first page. With the 6.c.iii workaround, and the heretofore-standard page lengths, and the 1id-guidelines-required text, several lines spill onto the second page. Ah, simplification, isn't it grand? Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [xml2rfc] [Trustees] Last Call for Comments: Proposed work-around to the Pre-5378 Problem
On Sun, Feb 22, 2009 at 12:36 PM, Ray Pelletier rpellet...@isoc.org wrote: On Feb 22, 2009, at 7:30 AM, Julian Reschke wrote: - where should the escape clause appear in an I-D (in Status of this Memo, or in Copyright Notice)? Copyright Notice I believe this change from historic practice (moving ipr-related statements from Status of this Memo to Copyright Notice) will require a new spin of the xml2rfc changes that I completed over the weekend. Is this really a good change to make right now? Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [webtools] IPR 765 is missing, More TLS-Authz misconduct?
On Mon, Feb 2, 2009 at 10:53 AM, Dean Anderson d...@av8.com wrote: https://datatracker.ietf.org/ipr/765/ reports 'the page you were looking for couldn't be found' This is a bug in the web page; it should report This IPR disclosure was removed at the request of the submitter.. The IPR index page at https://datatracker.ietf.org/ipr/ does properly report this status. Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
On Wed, Jan 14, 2009 at 1:41 AM, Tom.Petch sisyp...@dial.pipex.com wrote: Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. This is not quite accurate. RFC 5378 became BCP 78 at the time of publication on November 11th; even the old text says This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So if you published an I-D with those words in it after RFC 5378 was published as BCP 78, then that I-D is subject to the rights, licenses and restrictions contained in RFC 5378. Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Thu, Dec 11, 2008 at 3:40 PM, John C Klensin john-i...@jck.com wrote: ... the Trustees now believe that it is reasonable to [re] impose a deadline that gives the community two working days (it is already well into December 12 in much of the world) to modify and update tools to incorporate the new boilerplate. They gave one working day of notice that they expected the tools to be updated to begin accepting the new boilerplate last month, so this notification is at least twice as reasonable. Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New boilerplate (was: Re: Gen-ART LC Review of draft-igoe-secsh-aes-gcm-00)
On Wed, Nov 26, 2008 at 5:23 PM, Doug Ewell [EMAIL PROTECTED] wrote: Ben Campbell ben at estacado dot net wrote: --Don't forget the new boilerplate, depending on the timing of publication I submitted a draft earlier today and (reluctantly) had to settle for the old boilerplate, because: (a) xml2rfc doesn't yet support the new boilerplate There's a new release now - 1.34pre2 - which generates the new boilerplate for new documents. It's not a final release yet because it sometimes generates new boilerplate for old documents, too. (b) the official Legal Provisions document is 6 pages of legalese, and I'm not enough of a lawyer to sort out which parts I'm supposed to insert where, and what existing text I'm supposed to remove. As far as I know, sections 6.a and 6.b are the required bits, and 6.c can be used to restrict derivatives or publication. These replace all the boilerplate except the I-D boilerplate (e.g., remove anything that currently appears in http://www.ietf.org/ietf/1id-guidelines.html#iprnotices or http://www.ietf.org/ietf/1id-guidelines.html#anchor3). (Why am I pointing at a document with me as an author that describes the old boilerplate? I passed off authorship to this document because I am wary of the apparently-litigious nature of a couple of participants in the ipr wg, and I'm not covered by the IETF's liability insurance any more.) Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Removal of IETF patent disclosures?
On Aug 13, 2008, at 7:10 AM, Harald Alvestrand wrote: However, if people were filing disclosures that would not be useful (slanderous statements, duplicate-by-accident filings, stuff that turns out to be false and which the submitter wants redacted), we thought that having the discretionary ability to remove disclosures was a Good Thing. I have to admit that I found the removed state a bit mysterious. The [EMAIL PROTECTED] alias got a bug report: this previously filed IPR statement is now a 404. I investigated lightly and discovered that it was in the removed state, and decided that this was an error in the tool's handling of removed. Knowing that removed was really intended for spam makes the tool's handling of removed correct (pretend it doesn't exist), and the IPR statement being in the removed state incorrect. (Another problem with removed is that there's no annotation as to why it's removed, or when, or by whom. *sigh*) Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Transition status (was Re: ISO 3166 mandatory?)
On 2/20/08, John C Klensin [EMAIL PROTECTED] wrote: How much more of this will it take before you conclude that we have a problem? John, Forgive me for saying so, but this sounds like a very extreme response to me. (Unless the expected answer is A lot) During a transition like this, there are hundreds of things to manage. Several of the I-D submission problems were due to the code supplied by NSS being less portable than most applications; one problem that I'm aware of was due to a bug in idnits, which would have been triggered by either the old installation or the new one. When writing a tool to accept meeting registrations, let's say you are a random web app developer and you want to give the user an opportunity to pick their country from a drop-down list. What set of choices are you going to give them? Over the last several years, I've been fairly closely involved in the IETF's IT infrastructure; I've been quite impressed with how well the transition is going. Problems are being acknowledged and fixed quickly. The AMS staff is very knowledgeable, but the system they were given was basically undocumented and requires a fair amount of TLC to keep running day-to-day. One input to setting expectations for how this transition turns out should be the quality of the input. At this point, instead of worrying about the fact that there have been hiccoughs during the transition, I'd congratulate AMS for a job well done. The web site, in my experience, is significantly more responsive when browsing the mailing list archives. While there have been hiccoughs in the tools, they worked (and continue to work) to resolve them. Bill ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On 11/7/07, Bernard Aboba [EMAIL PROTECTED] wrote: Here is a different take on what happened: ... There are all sorts of takes on what happened. What I was told at the time was that the CARP developers picked protocol 112 specifically to interfere with VRRP, to get back at the IETF for not accepting their anti-patent position and to show the IETF how irrelevant they were. My impression was always that the various other stories were fabricated to cover up that decision. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
For example, see: http://kerneltrap.org/node/2873 That message appears to be based completely on conjecture - for example, their assertion based on looking at the list of assigned numbers ignores the fact that all of the numbers they based their supposition on were assigned before the rules were put in place. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Experimental makes sense for tls-authz
On 10/27/07, Andrew Newton [EMAIL PROTECTED] wrote: These are all excellent points, but looking over this draft it is not obvious that there is a documented patent claim. I have to get to the boilerplate at the end, follow a link and do a bit of searching. Perhaps the IETF ought to consider a Known IPR Claims Section in drafts/RFCs. RFC 2026, section 10.4.(D), gives boilerplate to add to a document where there is known ipr: The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. RFC 3667 removed this policy, because the absence of a notice in the document doesn't mean that an ipr claim wasn't filed after the RFC was published. A notice can only tell you that there is a claim, but the absence of a notice only means that there was no claim at the time of publication, not that there is no claim. Changing this back would be a topic for the ipr wg. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A pattented standard is not a standard
On 10/26/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Is this an official FSF campaign? Yes, http://www.fsf.org/news/oppose-tls-authz-standard.html Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC3678: header incompatibility
i am under impression that may include sys/socket.h clause can lead to portability issues in applications - some application writers will include netinet/in.h only and it will compile fine on some platforms, and not on some other platforms. Header pollution definitely makes it easier to write nonportable applications. do you have any information about when the clause was introduced? was it with the use of sockaddr_storage? I'd guess so, but I don't know for sure. You can see that the SUSv2 that you pointed to didn't have sockaddr_storage. Starting with a different angle: if there had been a different way to design the API, I think we would have. The use of sockaddr_storage in these structs is incredibly wasteful, since it's usually way bigger than a sockaddr_in6, which is the biggest thing that it has to convey. However, we were aware of no other socket option calls that required copying additional user memory to kernel memory (e.g., because we passed a pointer in the middle of the struct) and didn't want to introduce that requirement for fear of being difficult to implement on some platforms. The best option might have been to introduce a real new API, not just socket options; obviously then we could use similar options to bind()/connect() et al. and just accept a sockaddr * as one of the arguments. But this is a somewhat higher implementation overhead - updating libc, syscall tables, etc - and IPv4 multicast didn't do this - so again it was a matter of trying to reduce barriers to imnplementation. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
A good start would be explaining what exactly went wrong with the DHCP server(s) this time. We have a problem and we're working on it is not all that helpful. I wasn't directly involved in debugging this, but this is what I gathered from later discussions: The bottom line seemed to be a DHCP server that was configured to use DNS UPDATE combined with a DNS server that was configured to refuse DNS UPDATE. The DHCP server started out working OK, but apparently had more and more threads working on sending updates to the DNS server and started to fail to be able to usefully send DHCP responses. After a restart, it would serve fine for a while and then bog down again. Each tweak to the configuration would seem to fix the problem since the associated restart would cause service to be zippy again for a while. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: In support of symbolic references
On 4/5/07, John C Klensin [EMAIL PROTECTED] wrote: ... xml2rfc ends up with symbolic references that look like [I-D.rfc-editor-rfc2223bis] (one of the less unattractive ones) or, potentially, [I-D.draft-narten-iana-considerations-rfc2434-bis]. Those things cause formatting problems, violate almost every known style manual about forms for symbolic references, and so on. If our tools permitted us to use the forms that are recommended in the rest of the world, such as [Nart07a] for the above, it would be different. But they don't permit doing so conveniently. I wrote an xsl transform that does this. xml2rfc mydoc.xml mydoc-tmp.xml xsltproc strip-id-references.xsl mydoc-tmp.xml mydoc-tmp2.xml xml2rfc mydoc-tmp2.xml mydoc.txt http://rtg.ietf.org/~fenner/ietf/xml2rfc-xsl/strip-id-references.xsl (Not to say that this is convenient, but it's at least possible) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard
On 2/27/07, McDonald, Ira [EMAIL PROTECTED] wrote: Yes - from the IEEE/ISTO Printer Working Group, see the Job Monitoring MIB (RFC 2707) which defined the textual convention 'JmNaturalLanguageTagTC' Ah, silly me, I forgot that I hadn't written the part that populates the database with TCs yet. I wrote that part and indeed found JmNaturalLanguageTagTC. Interestingly, I couldn't find any objects that used this TC, in Job-Monitoring-MIB or any MIB published in an RFC. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard
On 2/10/07, McDonald, Ira [EMAIL PROTECTED] wrote: With respect to max length of 60, the public MIBs that I'm aware of often use 63 octets Do you have any pointers? I searched my MIB object database for objects named *Language* or with DESCRIPTIONS with Language inside, and only got the IP-MROUTE-MIB and MALLOC-MIB ones. The MALLOC-MIB one was interesting, since it uses IPMROUTE-STD-MIB::LanguageTag(1..94). Thanks, Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-norm-ref (Handling Normative References for Standards Track Documents) to BCP
On 2/24/07, Sam Hartman [EMAIL PROTECTED] wrote: I think there's a good split between RFC 3967 and this document. RFC 3967 will cover informational documents; this document will cover standards track. I have to admit that when I was reading this document I was confused by section 4; I thought for a while that the draft-klensin-norm-ref rules could be applied to informational references, but then the first paragraph of section 5 says it can't. It took me a while to understand that section 4 actually refers to annotating downrefs approved under the existing rules. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
On 2/23/07, Adrian Farrel [EMAIL PROTECTED] wrote: The reference to RFC3986 includes ..., Was Internet-Draft It is unusual to include reference to the I-D that has subsequently become an RFC. Probably best just to leave this text out. Ditto RFC3305, RFC3414, and RFC3415. Sorry, this one is my fault - I generate a set of include files for xml2rfc that has nearly all of the info that I know about a document, which I built to try to help me notice (if I ever read the references section of my own documents) when I've accidentally referred to an I-D that's been published or obsoleted, etc etc. David used them (I'm actually a bit curious how, I do make them available for rsync but I didn't think I had told anyone about that) and so got the extra info. He's taken kind of a beating for it so I feel particularly bad. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: submitting an ID
On 1/23/07, Edward Lewis [EMAIL PROTECTED] wrote: I have a question on section 3 of http://www.ietf.org/ietf/1id-guidelines.txt The short answer is that it was copied directly out of RFC 3978 (plus the modifications in RFC 4748). When I was updating 1id-guidelines, I erred on the side of exactly duplicating the text in the RFC, since the RFC is really what defines the rules. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: submitting an ID
On 1/24/07, Edward Lewis [EMAIL PROTECTED] wrote: What made this mysterious to me was why I failed to see my submissions get announced for some time. I never got any official feedback so I began to assume that the nits tool was the official word. When this happens, it's best to contact the secretariat to find out the status of the I-D submission (see the last sentence of section 7 of 1id-guidelines). Guessing is an ineffectual method of learning what caused the delay. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
John, Sorry to pick out a nugget from the middle of a very long message, but On 12/30/06, John C Klensin [EMAIL PROTECTED] wrote: ... What we don't need is more rigid rules that either try to anticipate every circumstance ... This is something that I feel very strongly about. We write rules with wiggle room, because it's impossible to anticipate every situation and important not to overconstrain the leadership in order to allow them to show ... leadership. We then look at the rules and say Oh horrors! Someone could use bad judgement and make something bad happen! and try to write more rules to prevent that. I think that instead we should try to select leadership that won't use bad judgement or will be able to understand when it's pointed out that they are. I think that long terms on the IESG tend to breed detachment from the community and a tendency to put IESG judgment ahead of that of the community and I don't think we can solve that with more rules about IESG behavior. As the current IESG member with the longest term, I agree with this, and that fed into my decision to not stand for the position again. I think a young [in terms-of-service] IESG is more likely to be a healthy IESG. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft status links on the wg pages?
Mike, Check out http://tools.ietf.org/wg/wgname and see if that gives you the view you're looking for. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: event calendar
On 10/16/06, Yaakov Stein [EMAIL PROTECTED] wrote: When clicking on http://www.ietf.org/meetings/events.cal.html one gets the event calendar that was posted a while ago. This may be an artifact of your system caching a previous result, as that document is solely a redirect, and has no content. I have no answer as to why the change was made. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
On 9/27/06, Dave Crocker [EMAIL PROTECTED] wrote: 2. It does not specify any syntactic detail for the domain suffix field of the DHCP option. Is it a dotted ascii string? Some other encoding? While I was confused too as to what this option is intended to be used for, I think that The domain suffix in the 'domain suffix' field ... MUST be encoded as specified in the section of RFC3315 titled Representation and use of domain names. sufficiently specifies the encoding of the domain suffix field. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]
On 9/18/06, Eliot Lear [EMAIL PROTECTED] wrote: I have not done the work to review velocity from -00 to RFC, but perhaps Bill Fenner has. I haven't; I've been concentrating on the IESG part of the document lifecycle. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NOMCOM term limits... Re: Now there seems to be lack of communicaiton here...
On 9/4/06, todd glassey [EMAIL PROTECTED] wrote: Its time to talk about term limits for NOMCOM appointments. Two or maybe three terms at most are enough. Todd, Given that there are no standing IESG appointees that have served for three terms, what exactly would making such a rule change? Arkko, Jari 0.2 Callon, Ross 0.2 Carpenter, Brian0.7 Dusseault, Lisa 0.2 Eggert, Lars0.2 Fenner, Bill2.5 Hardie, Ted 1.7 Hartman, Sam0.8 Housley, Russ 1.7 Jennings, Cullen0.2 Kessens, David 1.3 Peterson, Jon 1.7 Romascanu, Dan 0.2 Townsley, Mark 0.7 Westerlund, Magnus 0.2 (This is AD and number of terms served, where numbers of terms served is counted by adding up the number of IETFs the AD is listed under at http://www.ietf.org/iesg_mem.html and dividing by 6) Bill [to be fair, 2 of the above positions didn't exist until their holders were appointed 0.2 terms ago] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
A contractual requirement at this level of detail seems totally crazy. I'm afraid I agree. I see this in our other kinds of process specifications too -- we write rules for which you need to exercise sensible judgement, and then fret about what happens when someone uses bad judgement and try to write rules to prevent it. While it would be possible for a provider to win the RFC Editor contract, and fail to provide rsync, that'd be an exercise in bad judgement since they'd probably not get the contract when it was time to renew. While it's possible to tie down most (I dare not say all) loose ends in a protocol description, I can't imagine that you can do it in a process document or contract, and think you'll go crazy trying. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
Ok. So I'm not sure what you propose here - should we not require rsync and ftp mirroring capability, or should we ask for it, and not specify chapter and verse regarding version etc.? I'd certainly be very unhappy completely abandoning the rsync capability. I think that RFCs should be available via [at least] rsync, ftp and www. I think that a provider who provided less than what we have now [hint: we currently have more than that] would be exercising bad judgement and would probably lose the contract at renegotiation time - so are we trying to protect against someone getting the contract who doesn't actually want to provide services, or doesn't actually want the long-term business, or is actively malicious to the IETF, or what? Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
My recent experiences with ftp.ietf.org: EPSV doesn't work - it gives a port which it then isn't listening on (or, more likely since we get no response at all, a firewall blocks connections to): ftp ls --- EPSV 229 Entering Extended Passive Mode (|||42065|) ftp: connect for data channel: Operation timed out [simultaneously in another window] compost% telnet ftp.ietf.org 42065 Trying 156.154.16.149... telnet: connect to address 156.154.16.149: Operation timed out EPRT for IPv4 doesn't work - it returns an error Bad EPRT protocol. --- EPRT |1|192.20.225.40|56318| 500 Bad EPRT protocol. Apparently, the FTP server doesn't want to allow EPRT with IPv4. (1 is IPv4). It's not using the 522 I don't support that protocol error code, but is also saying that it doesn't support that protocol. PORT doesn't work - it returns an immediate error Failed to establish connection. --- PORT 192,20,225,40,219,254 200 PORT command successful. Consider using PASV. --- LIST 425 Failed to establish connection. tcpdump shows that it didn't send any packets trying to establish a connection to 192.20.225.40 and the 425 error comes too quickly to have tried. It looks like 3 out of 4 data channel establishment mechanisms are broken with this FTP server software and configuration for IPv4. I didn't test with IPv6. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF IPv6 platform configuration
Just for completeness, I configured 6to4 to get IPv6 working. Both EPSV and EPRT work with IPv6. ftp ls --- EPSV 229 Entering Extended Passive Mode (|||10283|) --- LIST 150 Here comes the directory listing. drwxrwxr-x 265 6060 48 8192 May 05 15:12 concluded-wg-ietf-mail-archive .. and ftp ls --- EPRT |2|2002:c014:e128::1|56420| 200 EPRT command successful. Consider using EPSV. --- LIST 150 Here comes the directory listing. drwxrwxr-x 265 6060 48 8192 May 05 15:12 concluded-wg-ietf-mail-archive .. Bill ___ 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: xml2rfc improvements (was: Re: Image attachments to ASCII RFCs)
On 6/20/06, Ned Freed [EMAIL PROTECTED] wrote: [jck:] ... I like a feature of those system that you didn't mention (the ability to insert comments whose appearance in the output can easily turned on and off. cref and some processing options comes close, but isn't quite the same). IMO this is something that needs to be added to xml2rfc. It is very common to have text of various sorts in drafts that has no business being in the final RFC, and the current mechanisms for controlling this are a bit primitive. Consider this a vote for some added functionality in xml2rfc to cover this case. Can you be more specific about what the requirements are? The xml2rfc maintainers are (rightly, IMO) reluctant to add features speculatively. cref exists for this purpose, but doesn't fit your needs because _? 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: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 6/20/06, Ned Freed [EMAIL PROTECTED] wrote: I don't know what needs to be done to make xml2rfc better, but I sure wish the RFC Editor would spend whatever time it takes with the folks who work on xml2rfc to accomplish this. Note that the next release will contain several features/changes that the RFC Editor asked for based on their experiences trying to use it for final document production. There are still some requests outstanding, since some of them would be quite difficult to implement and some were bug reports that nobody could replicate, but progress is definitely being made on this front. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 6/20/06, Bob Braden [EMAIL PROTECTED] wrote: [Alice] tells me that she entered several issues into the xml2rfc tracker, but she does not think anyone is looking at it any more. This is parly my fault - I picked the wrong technology for the tracker and it doesn't notify interested parties upon changes. I'm still interested in working on these problems but I'm so interrupt-driven that I don't often have a chance to poll the tracker. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why not PDF: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
On the other hand, here's a document that we've been working on for a while, always producing text and ps/pdf due to the inclusion of graphical state machines: -rw-r--r-- 1 fenner fenner 290444 Jun 9 14:34 pimspec.pdf -rw-r--r-- 1 fenner fenner 340594 Jun 14 14:32 pimspec.txt Interestingly, the PDF is smaller. I didn't tweak anything to get this - this was the completely naive create postscript from the nroff that generates the .txt and create pdf from that postscript workflow that we've been using for years. On the other hand, I created what ghostscript (AFPL Ghostscript SVN PRE-RELEASE 8.55 (2006-05-20)) claims to be PDF/A (I have to assume it's -1B since groff doesn't output pdfmark annotations for headers and footers), and it's much larger: -rw-r--r-- 1 fenner wheel 1540094 Jun 19 13:18 pimspec-a.pdf since this one has embedded font subsets even though they're courier, times and symbol. Bill ___ 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)
Having a more organized and documented source management mechanism in place would help. While I agree with your and Stephane's points, I think that's a seperate discussion to have. Bill ___ 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)
There is a reason it did not result in change... there were cogent arguments against all proposals that were made. I thought that some of the arguments were just arguments against change, and some of the arguments did argue for a change in the experiment but not that the experiment was bad per se. How DID it get last called, by the way? I evaluated the document, the discussion, the feedback from the stakeholders, and decided that a Last Call would be a good forcing function to make sure we have a real discussion about it. I think the idea has promise. How will a future implementor know which version is normative? Presumably, the documents will include a note, something like This document is part of an experiment described in RFC; unlike all other RFCs, the PDF version of this document is normative. Thanks for pointing out that the experiment description forgot to mention that. As Joel mentions, this experiment will have a negative impact on RFC Editor throughput. I didn't quite buy Joel's argument. If the author can generate ASCII from his source that matches the RFC-Editor's edited ASCII, and then generates the PDF from the same source, where does the extra verification come in? ...and the implications need more mature thought. If all we get when discussing on the ietf list is knee-jerk reactions, where is this more mature thought going to come from? Bill ___ 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)
(3) Given how popular xml2rfc is I think it makes sense to at least look at how it would best be used to produce PDF documents containing equations and block diagrams. I did this the N-2nd (or maybe 3rd) time we had this discussion and have refined it since. See, e.g., http://electricrain.com/fenner/tmp/draft-my-document-01.pdf . That's svg for the picture (also supported are gif, png, jpg, etc.) and latex for the equation. It's obviously just a proof of concept implementation. The editor screen when working on this document is something like http://electricrain.com/fenner/tmp/svg_eqn_editing.png . There's no WYSIWYG editing of the svn or latex, but you get to see what they look like. This is a $220 XML editor, but its job is mostly to string together other pieces of software so although it's not free software in this implementation, I don't think that means that the same thing can't be implemented with free software (e.g., it uses Batik to render the svg, and if Apache FOP improved some perhaps it could render the FOP to PDF instead of the for-pay (or free-to-download-personal-edition) RenderX) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
On 5/31/06, Fred Baker [EMAIL PROTECTED] wrote: On May 31, 2006, at 9:24 AM, Margaret Wasserman wrote: There isn't any documented appeals mechanism for IAB decisions. Should there be? Actually, there is. See section 6.5.3 of RFC 2026. Fred, Do you read that as being able to say the IAB made a mistake in their (RFC Editor selection|liaison management|other IAB-assigned task)? I read it as being able to say the IAB upheld my appeal to the IESG because RFC 2026 supports them, but RFC 2026 is wrong and nothing more. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
On 5/24/06, Bob Braden [EMAIL PROTECTED] wrote: In case anyone is unsure, the actual policy being followed by the RFC Editor will be found at: http://www.rfc-editor.org/policy.html#policy.authlist Bob, How does this policy relate to the one found at: http://www.rfc-editor.org/policy.html#policy.auth2 The Author Overload policy says that 'contact addresses may also be included in the Contributors section for those contributors whose knowledge makes them useful future contacts for information about the RFC'; the Authors vs. Contributors policy says 'can/should the Contributors section include contact information? With the clarification above, it should be clear that the answer will be: No, contact information should be in the Contact Information section.' Of course, that will be is predicated on the proposed renaming of Authors' Addresses to Contact Information; perhaps since that hasn't happened it can be assumed that the statement in the Author Overload policy is the one currently in force, but I find it a little confusing to have these apparently-contradictory statements on the same page. Thanks, Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF lists as RSS?
I wrote a poor-man's archive to rss some time ago for mhonarc. I never finished it because it wasn't clear it was what you really want (e.g., how do you pick what messages appear in the feed, etc.) but if someone wants to pick it up it'd be reasonably easy to change it to output atom and start experimenting. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
I also noticed that IPv6 disappeared from the network and reported it to the NOC. I think they figured out the problem at least in one of the APs or whatever it was. I've requested to know the reason but got no information at the time being. Jordi, At the heart of this problem was that we were using the hotel's existing switch infrastructure, since they already had ports all over the place, and it also allowed us to use their existing APs as well as our own. Unbeknownst to us, their switches were configured with the security options, 'switchport block unicast' and 'switchport block multicast'. The first meant that if the switch forgot a MAC address before the end device's ARP table did (e.g., because there are lots of MAC addresses flying around the network at a big meeting), that connectivity between the two systems would be blackholed. This caused a great deal of trouble with our monitoring station and also with the printers. The second meant that the IPv6 ND / RA packets, sent to arbitrary multicast addresses, were not forwarded since the switch didn't think that the multicast should go to these ports. After asking the hotel's provider to remove these restrictions, IPv6 worked again. There were still some isolated incidents which we were unable to completely debug but could be explained by some lingering 'switchport block' commands. This was the first time (to my knowledge) that we used a venue's existing infrastructure so heavily. It certainly taught us a few things. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
Mmm... well, my laptop (Mac Powerbook) fell off the b/g network several times, mostly during plenary sessions, but the problems were brief, and I usually had no trouble getting back on. Ken, I experienced this too, several times. Our best guess was that it had to do with the older IOS that was running on the hotel APs. This was another lesson learned about using someone else's equipment - it's not necessarily as up to date as the IETF needs. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP and TCP Headers' to Proposed Standard
Hi Geoff, Brian reminded me of your Last Call comment, which I saw and then overlooked. I think I meant to say No experimental addresses are assigned, where you took exception to saying ...defined. Do you find the following text sensible? 3.4.1. IPv6 Unicast Addresses [RFC2928] defines a set of IPv6 addresses for testing and experimental usage: The block of Sub-TLA IDs assigned to the IANA (i.e., 2001: ::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges. However, at this writing, there are no RFC3692-style experimental IPv6 addresses assigned. [I-D.huston-ipv6-iana-specials] creates an IANA registry which may in the future contain such assignments. For certain experiments, Unique Local Addresses [RFC4193] may be useful. It is not appropriate to use addresses in the documentation prefix [RFC3849] for experimentation. I don't feel comfortable asking for a unicast address range since I don't think the 3692 rules are clear enough for unicast addresses (like, who gets to advertise them?) so I'd rather just refer to the two relevant documents. Thanks, Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard
Juergen, I assumed, from reading in traceRouteHopsHopIndex about the behavior when a path changes, that the only safe thing for a manager to do is to read the hops from the table and render them to the user in order of increasing traceRouteHopsHopIndex but without necessarily showing the traceRouteHopsHopIndex to the user -- that it was perfectly reasonable for hops 1,2,3,4 of a 4-hop path to be numbered 1,8,12,35 (assuming that they started 1,2,3,4 but there were lots of path changes during the test). I think some people are assuming that the intention was that the values should be 1,2,3,4 (i.e., HopIndex == hop number) and that's why they're asking for a different definition. Perhaps the right direction could be to clarify that there is no connection between the value of HopIndex and traceroute hop, other than the ordering. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: xml2rfc updates
On 2/22/06, Mark Andrews [EMAIL PROTECTED] wrote: I noticed during AUTH48 that the RFC Editor Acknowledgment has been revised. Is there any intention of updating xml2rfc to reflect this? Yes. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard
Can we have a Proposed Standard without the IETF having change control? No. RFC3978 says, in section 5.2 where it describes the derivative works limitation that's present in draft-santesson-tls-ume, These notices may not be used with any standards-track document. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/11/06, Henrik Levkowetz [EMAIL PROTECTED] wrote: the tools team has not received any feedback or comments from the RFC-Editor regarding the xml2rfc tool. If we had, we would have forwarded it to the xml2rfc list. Aaron (for the RFC Editor) asked me to proxy their findings, and I worked with Charles and Marshall directly instead of going through the list; perhaps this was a mistake. The comments from the RFC Editor can be found at http://rtg.ietf.org/Members/BillFenner/rfced-xml/FrontPage/issuetracker, and many of them are fixed in xml2rfc 1.31a4. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/10/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 9:45 AM -0500 1/10/06, Brian Rosen wrote: Do you have any idea how painful it is to build any kind of product that has good management simply because there is no library of MIBs, with references to documents? There isn't even a LIST of IETF MIBs. You can't figure out if a document has a MIB unless you actually look at the text (although many have a big hint in the title of the document). So yes, I believe better MIB tools would lead to better products, although it would be hard to prove it. Why does this need to be done in the RFCs or Internet Drafts themselves? Why, for example, can't a human with a bit of training extract all the MIBs from the current RFCs and put them into a repository that is machine-accessible? Something like http://www.icir.org/fenner/mibs/mib-index.html and http://www.icir.org/fenner/mibs/extracted/ ? Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Alternative formats for IDs
On 1/11/06, Dave Crocker [EMAIL PROTECTED] wrote: 2. Given that the RFC Editor has the current practice of converting .txt submissions to nroff, it is equally reasonable to pursue their changing that conversion, to instead be into xml2rfc. I don't think that converting to xml is the same class of work. There's a great deal of semantic information that should be encoded in the XML that isn't in the submitted text and doesn't have to be in the nroff. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ABNF Re: Troubles with UTF-8
On 1/5/06, Tom.Petch [EMAIL PROTECTED] wrote: You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. ABNF uses non-negative integers to represent characters - note that it explicitly doesn't specify a range (2nd sentence of section 2.3). RFC 4234 specifies the encoding of those integers into ASCII, and says that other encodings may be specified. There's an implicit (obvious) encoding of ABNF characters into Unicode, and as Misha pointed out the IRI spec uses it - technically maybe it needs to be spelled out somewhere. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. That's an example, which is probably missing the word US-ASCII between printable and character. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Lemonade Profile' to Proposed Standard
On 12/16/05, Frank Ellermann [EMAIL PROTECTED] wrote: Thanks. I tried to find out what lemonade stands for, back to an obscure IETF 55 PDF on an obscure lemonade WG page, and finally came to the conclusion that it's just a name and no acronym... I hope that's correct ;-) Sorry, that's my fault. It originally stood for License to Enhance Messaging Oriented Network Access for Diverse Endpoints, and I couldn't figure out what that meant the WG would do. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
On 11/29/05, Sam Hartman [EMAIL PROTECTED] wrote: However the update behavior if you add agility is more complicated. I think this is the key to the objections, and deserves a lot of consideration. Adding agility would presumably require either a) Requiring that all consumers of DHCID records are configured to use the same hash algorithm, or b) Requiring that the DHCID record encodes the hash and possibly permitting multiple hashes for the same data. The problem with b) is that it changes the UPDATE process - right now, or with a), the DHCP server sends an UPDATE to the DNS server saying If this name exists, and if the DHCID record matches this string, then delete the existing records (and add the new record(s) (draft-ietf-dhc-ddns-resolution section 6.3.2). This is an atomic operation - the query, match and update. If the DHCP server doing the UPDATE doesn't know what hash to use a priori, it has to query the existing record to find out what hash to use, changing this to a multi-step process with possible associated race conditions (I think you can eliminate them, but you have to be careful). This is almost certainly what is getting the pushback. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On 11/24/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: If we adopt some new format, though, I think we really need the ability to generate diffs of different versions of the same document. The solution that comes to mind for diffs is to format the old version (to text), format the new version, and use the existing tools (htmlwdiff, rfcdiff, or others). There's no sensible way to do a diff of a graphic so I think diffing the text form is sensible. If it's to be the input of wdiff, it's be feasible to create an XSL transform that generates text (it's tough to wrap to 72 columns and add headers and footers in XSL, but wdiff would (might) make that unimportant), so that diff generation isn't reliant on an installed xml2rfc. I have a transform that I wrote when I was first learning xsl that translates to nroff -- not particularly useful in this context but a proof of concept for going to some textual form. (FOP's txt renderer looks attractive, except that it gets the spacing wrong - I just tried it with Julian's FO scripts and got The three-stageIETF standardizationprocessisdescribed inBCP 9,RFC 2026 [RFC2026]. Inbrief,thethree stagesofInternetstandardizationareProposed (which requiresa wellwritten,openly reviewed specification), Draft(which requiresProposed status,multipleimplementations and some operationalexperience),and full InterneStandard (which requiresDraft statuand more extensi veoperationalexperience).Historically, increasedrequirements,originallydocumented inRFC 1264 [R FC1264], have been appliedto protocols produced withinthe Routing Area. ) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Henning's proposal (Re: ASCII art)
On 11/23/05, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: To be specific if you can make up an example XML I-D with an embedded SVG diagram, and tell me which tool I can use to manipulate the diagram inside the XML I-D, I'll have a much bigger basis (1 example rather than zero) on which to evaluate whether I think it's feasible or not. Harald, This is not quite embedded, but that's a detail: I created a random svg file with Inkscape, a cross-platform svg drawing app. I created an artwork element with src=pretty.svg; it displayed inline in the cross-platform xxe XML editor using my xml2rfc plugin (but no inline editing of the graphic) and converted to PDF reasonably well: http://electricrain.com/fenner/tmp/svg-demo.xml is the draft; http://electricrain.com/fenner/tmp/pretty.svg is the picture; http://electricrain.com/fenner/tmp/XMLEditorScreenSnapz011.png http://electricrain.com/fenner/tmp/draft-my-document-00.pdf (OK, so the graphic is cut off in the PDF, but isn't in the preview or in the graphic editor. I don't know exactly whose goof that is -- Inkscape shows it properly, as does Batik; both Apache FOP 0.20.5 and Adobe's ancient SVG plugin show it cut off. Perhaps someone who knows more about SVG can talk about this.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFCs should be distributed in XML (Was: Faux Pas -- web publication in proprietary formats at ietf.org
On 11/16/05, Ted Faber [EMAIL PROTECTED] wrote: I think Bill was talking about making his editing plug-in display changes to the document as change bars or whatnot. Right, whatnot. In actual fact, what I have been thinking of was a change-acceptance function for copy editing (show old, show new, show both, accept new, reject new, create alternate new) - not particularly what you want for day to day change control. Straight revision control systems aren't actually that good for XML that's been edited in an XML editor, since they tend to pretty-print the XML when saving, and people using 2 different editors could end up creating diffs on every line. (Of course, one could use a front end to the revision control system that formatted the XML and used rfcdiff on the result...) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFCs should be distributed in XML (Was: Faux Pas -- web publication in proprietary formats at ietf.org
On 11/14/05, Stewart Bryant [EMAIL PROTECTED] wrote: I would not mind swapping from to an XML package provided it supported change-tracking, embedded comments, highlighting, WYSWYG display, edit time spell and edit time grammer checking, and was a simple to install and maintain on XP. Is there such a package? My xxe plugin, http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/, provides a few of the features: - embedded comments (with cref) - WYSIKLWYG (What you see is kinda like what you get) display - Edit time spell check It's based on the XMLMind XML Editor, which is an excellent cross-platform java-based XML editor, which is not open-source but has a free Standard Edition and an excellent Professional Edition. My plugin works fine with both, but certain features such as PDF output are limited to the Professional Edition. I've been pondering change tracking, in the context of copy-editing, but I haven't come up with a complete thought yet. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Diagrams (Was RFCs should be distributed in XML)
On 11/14/05, Joe Touch [EMAIL PROTECTED] wrote: Where's the modern, WYSIWYG, outline-mode capable editor? And does one exist that's free? Still a work in progress, but see http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ . Outline mode is high on my todo list (I have one working that only does top-level sections, but haven't gotten it working showing all sections yet.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please make sure that you do not run your WLAN in ad hoc mode
On 11/10/05, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: Put up a screen in the hallway with continuous display of the ad-hoc mode MACs detected at any time. Lets people check their own MACs in real time. If people don't know how to turn off ad-hoc mode, will they know how to check their MAC address against the list? Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2606bis
On 10/19/05, Frank Ellermann [EMAIL PROTECTED] wrote: ... to see a big red blinking WAIT for each normative reference to an informational RfC. Not if the RFC 3967 procedure is followed (Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We will require all ADs that are the ADs for Bob to change their name formally to Bruce. Eric, That's the best idea I've heard yet. Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: regarding IETF lists using mailman: nodupes considered harmful
On 8/25/05, Keith Moore moore@cs.utk.edu wrote: Recent versions of mailman set nodupes by default. List participants can change it if they know about it, but they might have no idea of how this setting works and how it can be used to exclude them from participation. The workaround is to set new_member_options (under General Options) so that Filter out duplicate messages to list members is NOT set. Do not send a copy of a member's own post should probably not be set either. When Rob Austein and I discovered this (geez, it must have been a year ago or more), there was no obvious way to change the default (looking at UI and code), so we put it off - I guess for long enough that the UI might have caught up... I noticed it because I tend to delete the version of a mail to list+me that ends up in my inbox, because I know it'll end up in my listbox too, and that stopped happening. The action to recommend to existing users is to go to your options for some list, e.g., https://www1.ietf.org/mailman/options/ietf , scroll down to the bottom, in the Avoid duplicate copies of messages? box, select No and Set globally, then Submit my changes. If someone with a little more mailman clue than I can figure out a withlist script (or similar) to set this default for all lists and all users that'd probably be quite useful. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: regarding IETF lists using mailman: nodupes considered harmful
Sorry to follow up to my own message; I discovered when setting up rtg.ietf.org's mailman setup that putting DEFAULT_NEW_MEMBER_OPTIONS = 0 in mm_cfg.py will turn off the nodupes option for new lists. It'll still be on by default for existing lists, and existing subscriptions. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Tags for Identifying Languages' to BCP
JFC, In March, 1995, when RFC 1766 was published, the BCP track did not exist. The Standards Track was being used for things that were not protocols and did not fit well into the 3-stage process. Since BCPs are subject to the same consensus judging and scrutiny as standards-track documents, it's been common practice to obsolete old standards-track documents with BCPs when it's reasonable to think that the original document would have been a BCP if BCPs had existed at the time. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why have we gotten away from running code?
On 8/7/05, Jeroen Massar [EMAIL PROTECTED] wrote: Maybe there should be requirement that before having going to Last Call there should at least be 2 separate implementations when a document is created by a working group? The Routing Area is debating having this rule. Right now, the rules laid down in RFC1264 include 1) Documents specifying the Protocol and its Usage. The specification for the routing protocol must be well written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol. The best evidence for ...possible to develop... is, of course, another implementation. Our draft update for 1264 is draft-fenner-zinin-rtg-standard-reqts-00 . Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Keeping this IETF's schedule in the future...?
I agree completely; I've had trouble with evening sessions for a couple of years now, and find this schedule MUCH easier to manage. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Why would you want to have a calender without timezones?? Mostly for clients with bad user interfaces - e.g., old Apple iCal which didn't let you set the display time zone differently from the system time zone, or web-based calendar servers that don't allow the visitor to set the display time zone. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
P.S. - being curious: A quick analysis of http://www.ietf.org/iesg_mem.html, counting terms by number of IETF meetings since that's how they're represented there, results in the following answers for the IESG. The IAB history page isn't as easy to analyze in the same way but someone certainly could do so. what are the max terms for the IESG and IAB in their history? 31 IETF meetings what are the average terms for the IESG and IAB in their history? 10.2 IETF meetings what are the average and max terms of the current participants? max = 28, average = 7.8 (This average counts Mark and Brian as having served 0 IETFs, based on the data set - the average counting just the 11 continuing ADs is 9.1) Bill Raw data at http://rtg.ietf.org/~fenner/ietf/terms.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: calendar file for IETF
Just for fun, you could try http://rtg.ietf.org/~fenner/ietf/ietf-63.ics ; this is a completely independent implementation of the same mapping so may have a completely different failure mode ;-) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
One important (IMHO) issue is that Bill's ics does not use timezone info for the times. This was a conscious decision. I think the obvious answer is to have two versions, one with timezone and one without. Couple of other points: - Some lines were longer than 72 characters Erk, I forgot about that aspect. - Some SUMMARY's contained raw HTMl mark-up This was an oversight when converting the HTML output to iCalendar output. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
It reads in to Thunderbird OK, but the result is less pretty than Eliot's effort. Eliot's version appears to lay out the multiple events in a partcular timeslot evenly across the available space, whereas Bill's results in different sized blocks and in some cases some of the events appear to be hiding others. This may be because mine treats two sequential 1-hour meetings as a 2-hour meeting, and Eliot's treats them as 2 1-hour meetings. See l3vpn on Monday and mip6 on Tuesday evening. I originally wrote the agenda parser that's the basis of this .ics output when we switched to 1-hour meetings on Tuesdays because I could never tell whether a given meeting was one or 2 hours long. I have yet to find a client that has a good variable-length overlapping event rendering algorithm, especially with 8-9 events in the overlap. Apple's iCal usually does really well when there are 3 or 4. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
hopefully the final result will be able to express the more complex forms of wedgitude such as your check was sent two years ago via IESG express under tracking number and is currently being held at our hub until it can be stapled to another check from a different working group So, e.g., for draft-ietf-ospf-2547-dnbit, is it enough to say Waiting for draft-ietf-l3vpn-ospf-2547 (IESG Evaluation :: AD Followup) and draft-ietf-idr-bgp-ext-communities (Approved- Announcement sent)? (Note that the 2nd one is a REF that's not there of a REF that is there). Is that too much to put on the summary page? Would it also be useful to put a link to, e.g., http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?doc=draft-ietf-l3vpn-ospf-2547docx=on for each dependency, to check further dependencies? (Yes, I should have a recurse and check all that dependency's dependencies option) (Note that these dependencies are all heuristically extracted and are a best case scenario) For draft-ietf-ccamp-lmp-mib, is it sufficient to say REFs cleared on 2005/04/20, or would you want to see more detail, that it was draft-ietf-mpls-bundle that was holding it up? I'm starting to think that for most of the complex relationships, we want a summary on the top level (e.g., draft-ietf-ospf-2547-dnbit could say REF to 2 drafts not in queue) and a detail page that gives you all the info - otherwise I'm concerned about cluttering up the top page. And, of course, a picture is worth a thousand words, perhaps I could find a way to fit http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf in there. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
On 7/19/05, Frank Ellermann [EMAIL PROTECTED] wrote:
It also breaks the RFC Editor's REF state into two seperate
states - REF-INT, where all of the REF documents are also in
the queue, and REF-EXT, where one or more is not. Only
REF-EXT is a blocking state.
REF-INT could point to REF-EXT, but you probably check this
condition.
Yes, and it took me an embarassingly long time to come up with an
algorithm that didn't recurse indefinitely ;-)
For one case I'm watching the editor queue says
REF draft-crocker-abnf-rfc2234bis-00, your script somehow
decided REF-EXT, maybe it's confused by the trailing -00 (?)
Indeed, the analysis knows to strip off (-[^-]{1,2})?.txt$ from the
ref; I've changed it to make the .txt optional and your example should
be correct in this afternoon's run.
Bill
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
Bruce Lilly writes: It would be nice to have something analogous to the I-D tracker for the RFC-Editor process, recording process state transitions and their dates. The parking area isn't really meant to be an analysis of the RFC Editor's queue, just a statement about what the IETF has approved. However, much of the followup has been with similar requests. I've been downloading snapshots of the RFC Editor's queue web page for a couple of years now; http://rtg.ietf.org/~fenner/iesg/analyze-rfcq.txt is updated daily and has the state changes that I've observed. It also breaks the RFC Editor's REF state into two seperate states - REF-INT, where all of the REF documents are also in the queue, and REF-EXT, where one or more is not. Only REF-EXT is a blocking state. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
Yes. And what's the idea ? It's the IETF's statement about having approved the documents, as opposed to the RFC Editor's statement about having the documents in the queue. So far I took e.g. draft-crocker-abnf-rfc2234bis-00.txt, removed draft- and -00.txt resulting in a fragment id. Unfortunately, whether or not you have to remove the draft- depends on who added the document to the queue and when. The RFC Editor said they would be working on getting this consistent but for now it's not very useful. And that's the position of 2234bis within its category non-WG standards track (chronological). The primary key on the parking area is simply the date (and I'm working on other sort orders). Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
It should be working now. (The danger of running on live data - when it changes in unanticipated ways, the page breaks!) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Test version of the Parking Area
Is this (239-element) table sorted? I might suggest sorted by ID name within WG, but any sort would be a good thing to provide. It's sorted by document approval date. I'll point that out in the header and look into making other optional sorts available. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On 6/9/05, Bruce Lilly [EMAIL PROTECTED] wrote: Conversely, if the IESG does regard the matter as important, it could: 1. direct the IETF Secretariat to enforce the rule Bruce, ID-Checklist is only for I-Ds that are submitted to the IESG for publication. It's not the cost of checking that is a problem, rather, it's useful to allow earlier drafts of I-Ds to not be fully fleshed out (thus they're .. well .. drafts?) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
On 6/9/05, Brian E Carpenter [EMAIL PROTECTED] wrote: It's not illogical - if your source file says rfc ipr='full3667'... you get exactly what you asked for, i.e. the obsolete boilerplate. The id-nits tool will warn you - it is well worth running that before submitting *any* I-D, whether produced by xml2rfc or another method. Another tool that is worth running on the xml source before using xml2rfc on it is at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ ; it will check that the source is well-formed and valid according to the DTD (XML generated outside of a validating editor is often not valid, and sometimes even not well-formed, even though xml2rfc creates a fine-looking document from it), and also checks for various other errors including the IPR requested. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
On 6/8/05, wayne [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED] Randall Stewart [EMAIL PROTECTED] writes: as the very first paragraph.. .this was generated via the XML tool.. So, I guess the automated tool will no longer accept this statement with a reference to RFC 36668 it has to be BCP 79... and the section number. It is my understanding that v1.30 needed to support the lastest IPR boilerplate. 1.29 supports the latest IPR boilerplate, and was released before the requirement changed. You do have to be sure to update the ipr= attribute in your source document. Be aware that v1.30 also changes some formatting and this can lead to a fair amount of work to fix things. I'm not sure if you mean 1.29 here or the as-yet-unreleased 1.30. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
My historical data on document progress in the I-D tracker, collected since the beginning of 2003, is available at https://rtg.ietf.org/phpmyadmin username ietf password ietf; pick database trackerdata and table dochistory. (Ignore the permission denied error; go straight for the table list on the left or the SQL tab on the top of the right pane) A starter query to somewhat understand the table relationships is SELECT docname, changedate, statename, substatename FROM dochistory, docs LEFT JOIN states ON stateid = newstate LEFT JOIN substates ON substateid = newsubstate WHERE docs.docid = dochistory.docid ORDER BY dochistory.docid, histid; (This will return some NULL transitions where something other than the substate or substate transitioned, like the version number, etc.) I don't have any great ideas on how to do the analysis, but at least I have some data to supply. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: More pretty graphs
On 5/17/05, Bruce Lilly [EMAIL PROTECTED] wrote: Interesting, but the key could be clarified I've tried to clarify the key, and have added a red diamond for nonexistent I-D (which was previously confusingly represented as an individual expired document). Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: More pretty graphs
On 5/17/05, Frank Ellermann [EMAIL PROTECTED] wrote: Nice. I know that I need glasses, but maybe you could arrange for bigger figures with a bigger font size ? Frank, I used PDF because most PDF viewers allow zooming and panning. I've left graphviz to decide on the layout itself, since for complex groups (see some of the larger PDF files), there's no way to sensibly influence the graph layout. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
More pretty graphs
Based on the positive feedback from my RFC-Editor graph, I've updated some work that I started some time ago - a set of graphs, two per working group. These graphs show inter-document dependencies(*) of all I-Ds that are working group documents, and one hop forwards and back - for example, if a foowg document depends on draft-fenner-great-stuff, then the individual draft shows up, but not *that* document's dependencies. The two graphs are wgname.pdf, which includes relationships that my script could determine are not normative, and wgname-norm.pdf which does not. Sometimes when the full graph is too much, the -norm graph is still readable. It's an interesting way to see what relationships exist, and what other groups / documents may be referencing a given WG's work. http://rtg.ietf.org/~fenner/ietf/deps/viz/ Each page includes a key for what the shapes and colors mean. Feedback is welcome. Bill (*) - Of course, these dependencies are gathered programmatically, using heuristics run over Internet Drafts, looking for filenames of other drafts. This means that some dependencies are not found - e.g., references like [Ken-Arch]Kent, S., and Seo, K., Security Architecture for the Internet Protocol, RFC ???, ??? 200?. that are meant to be to an I-D are never seen in my data. (I'm not picking on IPsec or this reference format - just noting the limitations of my heuristics) The type of reference is also picked up by heuristics, looking for sections titled, e.g., Normative References. I'm happy to look at the specifics of any document that the heuristics failed on. The actual data behind the graphs can be seen in my mysql database; https://rtg.ietf.org/phpmyadmin/ user ietf password ietf database draftdep table dep ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
On 5/11/05, Margaret Wasserman [EMAIL PROTECTED] wrote: Also, if there is the equivalent of the I-D tracker for the RFC Editor Queue (where correspondence and major state transitions for a document are captured and can be seen later), I am not sure where to find it. The RFC editor queue is a text document that only seems to capture the current state of the document (EDIT, AUTH48, etc.). I've been collecting a daily snapshot of the RFC Editor's queue since mid-2002; http://rtg.ietf.org/~fenner/iesg/analyze-rfcq.txt (updated daily) has ananalysis of every single document and state it's gone through since then. (That's where Thomas's example came from.) It doesn't have correspondence, and you have to download the whole file and search it for the document you're looking for, but at least the state change data is there. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Bill et al, You may be interested in http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf for a visualization that I've been fine-tuning for a couple of years; it's auto-generated daily. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
On 5/11/05, Dave Crocker [EMAIL PROTECTED] wrote: You may be interested in http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf for a visualization that I've been fine-tuning for a couple of years; it's auto-generated daily. wow. neat! what is the difference between the green and red circles? what is the difference between the black and gold lines? Sorry, the key is on the previous page, http://rtg.ietf.org/~fenner/iesg/ - oval colors map to RFC-Editor state as below. Arrows indicate dependency. Box with orange arrows inside indicates a cycle; large cycles are hard to detect without looking for them. color state green EDIT red REF blueIANA black other dotted blackNot in queue (The orange arrows were the original reason for this; I thought the big glorp of ccamp documents was stuck because it was a 7-hop interdependency so each document had what appeared to be unresolved dependencies) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On 5/9/05, Lars-Erik Jonsson (LU/EAB) [EMAIL PROTECTED] wrote: More direct communication with individual ADs (especially ADs from other areas who do have comments on what a WG has produced) would hopefully also reduce the number of myths about IESG/AD operations. Indeed. Of course, the idea of having someone in the middle is really that they will *facilitate* the discussion, so maybe we can find a way to keep both aspects - direct communication and facilitation. On 5/9/05, John Loughney [EMAIL PROTECTED] wrote: When is a DISCUSS not a discuss? When it is a You have to fix this and I'm holding a DISCUSS until it's fixed. I've seen variations on there as a draft editor and it's not always clear. Well, for things like This misuses MIME in a way that will cause problems in the future or This type of security has known flaws and it would be better to go this other way, yes, it tends to be fix this, period. These are the backstop issues that Brian mentioned (that the IESG would rather get out of the business of catching). It helps to have an explanation of the DISCUSS. Certainly. In theory, a DISCUSS without an explanation is not valid, and I think the IESG has worked hard in the last couple of years to provide actual reasons for DISCUSSes. As you may know from a few IETF plenaries, I've been collecting various bits of data; of the 475 DISCUSS evaluations in my database (which, it turns out, includes some that have been resolved; I have to update my data collection methodology), only one has no text associated with it, and that one is one of the ones associated with the buggy methodology, i.e., has been resolved. (Of course, my database has no idea if the text that's there is relevant or useful, but at least we're above the lowest hurdle) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: text suggested by ADs
On 5/7/05, Dave Crocker [EMAIL PROTECTED] wrote: If someone has the authority to block the long-term work of a group of IETF participants, they have an *obligation* to take their concerns directly to those participants and engage in a direct process to resolve it. Dave, From my point of view, there are two assumptions that the IESG makes in this situation: 1) Since the responsible AD (or PROTO shepherd) is more familiar with the working group / document / other work / etc, they will be able to more effectively communicate the concerns. 2) The AD that registered the DISCUSS is always willing to actually have a discussion directly with the WG or authors if necessary. However, I think that the community tends to see instead: 1) The discussing AD is hiding behind a shield 2) The discussing AD isn't willing to communicate with the WG I've certainly seen responses to discusses that I've filed come back as Well, I don't think this is reasonable, but I've made this change to satisfy the IESG, even though I would have been willing to have the discussion and yield to the WG's/authors' opinion. I do think that #1 is solving a real problem - I'm pretty sure that WGs/authors would rather get one message summarizing all of the IESG's issues rather than 10 messages from different individuals that might have overlapping issues, etc. However, if it's perpetuating the myth that ADs aren't willing to talk to the WGs/authors, we need to do *something* about it. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On Apr 8, 2005 5:27 AM, Scott W Brim sbrim@cisco.com wrote: On 4/7/2005 10:36, Brian E Carpenter allegedly wrote: prefer nroff: 8 prefer xml: 37 neither: 9 I wonder how many of those have actually written a draft using both? I picked neither since I use both and don't have a strong preference. nroff gives me much more control over the actual formatting, xml lets me leave the tool maintenance to someone else and I do see the advantage of well-formed metadata. (otoh I have nroff macros to help in writing MIBs, which e.g., create the SEQUENCE so it's never out of sync with the objects in a table... can't think of how I would do that in XML offhand) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On Apr 8, 2005 6:48 AM, Bill Sommerfeld [EMAIL PROTECTED] wrote: my biggest gripe is the fact that (as of the last time I looked) the draft version is taken from the input filename rather than text internal to the file If you use rfc docName=draft-fenner-xml-aint-so-bad-01, and run the tool like xml2rfc input.xml draft-fenner-xml-aint-so-bad-01.txt, then you can keep the input file named whatever you like. draft-fenner-literal-zoneid-01.txt was produced that way; its source filename is literal-zoneid.xml. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' toInformational RFC
On Apr 8, 2005 6:40 AM, Elwyn davies [EMAIL PROTECTED] wrote: That way you could get the best of both worlds... more or less WYSIWYG Construction for the bulk of the text and pictures, auto-insertion of boilerplate and some way to leverage the references stuff in xml2rfc. I've written a plugin for the XMLMind XML Editor that gives almost WYSIWYG editing of xml2rfc documents. See http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/ for a screenshot and download info. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On Apr 6, 2005 5:38 AM, Bruce Lilly [EMAIL PROTECTED] wrote: The biggest problem with XML editors is that they are unproductive. Editing XML in all of the ones I've seen goes something like: [mouse,icon,click,type a bit,mouse,...] I've found that I can mostly avoid the mouse using XMLmind's XML editor and my xml2rfc plugin (http://rtg.ietf.org/~fenner/ietf/xml2rfc-xxe/). xxe has been designed to have keyboard shortcuts for most common operations and I've tried to continue that (e.g., enter to insert a new paragraph or split the current one at the cursor). I have to admit that I use nroff about 75% of the time and XML about 25%, I'm much happier about the postscript/PDF output options from nroff than from XML, and I can't imagine having written the 120-page PIM spec in XML. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Requirements for IETF Draft Submission Toolset' to Informational RFC
On Apr 6, 2005 7:10 AM, Alex Rousskov [EMAIL PROTECTED] wrote: On Wed, 2005/04/06 (MDT), [EMAIL PROTECTED] wrote: I have to admit that I use nroff about 75% of the time and XML about 25%, I'm much happier about the postscript/PDF output options from nroff than from XML, To be fair, poor output quality is not XML's fault, it is tool's fault. Popular tools improve with time (and IETF can influence/speedup such improvement if needed). Very true - I'm just talking abot the current state of affairs. and I can't imagine having written the 120-page PIM spec in XML. My largest XML-based RFC is only 60 pages, but I do not see why 120 pages would be too long for XML. Can you clarify? Just curious... Well, I think the main reason is that any time we needed custom handling for a topic it was easy to write a macro to handle it; the same thing in XML would probably mean adding preprocessors (perhaps an xsl transform). We also ended up with some tables that required some pretty fine tuning to get to fit in 7x characters; my gut tells me that would be harder to do in XML. Finally, the optional figures in the postscript version would not have been supported by the currently available tools. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
The spelling error comments above are attributed to The IESG. The IESG authored the Last Call message to which the spelling error comments were a reply. Ned quoted Bruce's attribution with no attribution (but it was indented with a prefix.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please review updated 1id-guidelines
On Tue, 1 Mar 2005 20:06:36 -0500, Bruce Lilly [EMAIL PROTECTED] wrote: It's unclear what the status of the document is intended to be. I suspect it should probably be a BCP RFC. It's intended to replace http://www.ietf.org/ietf/1id-guidelines.txt . Sect. 2 mentions six months for expiration, whereas the actual rule appears to be 185 days Indeed, the secretariat's review also caught this error; thanks! Sect. 2 mentions the instructions to RFC Authors document; that should probably refer (instead or additionally) to RFC 2223 or its successor (which the named document is apparently intended to become). The draft says 'This format is specified fully in instructions to RFC Authors (see the RFC Editor's Web pages and [I-D.rfc-editor-rfc2223bis]).' - is the reference there not the one you're suggesting? An error was made in conversion of 10 inches -- the text less than about 250mm should be replaced with no greater than 254.00mm. I did say about. I didn't think that the 4mm was particularly important; maybe I'm just remembering how stupid I thought it read when a book I was reading said ...about 621.37119 miles when it was converted from about 1000 kilometers. How about Internet Draft rather than the HYPHENATED-SHOUTING INTERNET-DRAFT? I don't mind removing the shouting, but the hyphenation is on purpose. Internet-Draft is meant to be a noun. There is a discussion about restrictions on content of the title -- RFC 2223 has text prohibiting a dot in the title rfc2223bis doesn't have this restriction. However, it's worth including 2223bis's restriction on acronyms. Section 3 gives some boilerplate text. I believe that some options should be available to conform that boilerplate to specific circumstances. I copied the boilerplate in sections 3 and 4 from the lawyer-approved text in RFC 3978. I'm not inclined to change it without advice from the lawyer (which I'm becoming convinced that I should seek - you're not the only one who wants to vary the text.) 1. I'd like to see a statement that spaces around (C) are optional and that PostScript and PDF versions may use the copyright symbol in place of a parenthesized C. Do you mean that Copyright(C)The Internet Society is acceptable? 2. Presumably the draft should not literally contain the characters (year) Indeed, that's why the document says 'The year in the copyright statement should be replaced with the current year.'. Can you suggest a way to make this more clear? should the year of publication be parenthesized or not -- it's not clear. I think the intent is that it is, but again, I'm just interpreting RFC 3978, I didn't write the boilerplate. In place of I accept in some boilerplate, the author accepts or the authors accept, as appropriate for the draft, should probably be substituted for consistency with other boilerplate. I agree, but the ipr working group didn't make this change in the updated RFC. I'm still discussing this section with the RFC Editor so these I accept options may just go away anyway. Section 4, paragraph labeled a raises some amusing issues Again, these are RFC 3978 issues. 1id-guidelines is reflecting the ipr policies, not making them. Section 8 discusses file names and tombstone files. Can we please add an IANA considerations section directing IANA to provide working links to draft files (or tombstone files) when registering some assignment based on a draft (prior to publication as an RFC)? Currently, IANA has links from their web-based assignments tables that point to a non-existent file, which leads to an HTTP 404 error and a lot of work to figure out where exactly the particular assigned number is defined, how it is intended to be used, etc. I don't think 1id-guidelines is the place for this kind of specific instruction to IANA - but it is a reasonable request. I will bring this up during our IETF/IANA coordination lunch on Monday. What's the deal with Ignore this partial reference? It's a draft document and I wasn't focusing on the format of references. Regarding updating of references, consistent use of BCP numbers might save such effort in the future, since BCP numbers don't change. Well, the whole reason for this update to 1id-guidelines is because the content of BCP 78 changed between when it was published as RFC 3667 and RFC 3978, so I'm not sure that stability of reference is good in this context. There is either a stray bullet or some missing text on page 12. A stray bullet - sorry. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please review updated 1id-guidelines
The draft version currently has a link to http://www.rfc-editor.org/howtopub.html which has a link to the formatting page and much more. I'm happy to add more information, and I think Bruce's macros are a good addition to the set of available tools too. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Please review updated 1id-guidelines
Hi, I'm working on an update for 1id-guidelines.txt so that it will be ready to reflect the new IPR RFCs (RFC 3907 and 3908) when they are published. It's gone through one round of discussion in the IESG; now I'm looking for more complete review. Pieces that could use extra review: - Section 3 - in particular, are the 4 choices for copyright statements clear enough, and what type of document needs what? - Section 7 - the section on naming was redone, removing the part about asking the secretariat for a filename, and adding the rules for an I-D filename. - Section 9 - this was significantly updated to reflect the authors' responsibilities under 3667/3668 (it still said if you know about IPR, you should consider sending an IPR disclosure) The updated version is available at http://homepage.mac.com/billfenner/id-guidelines/1id-guidelines.txt or http://homepage.mac.com/billfenner/id-guidelines/1id-guidelines.html Diffs from the current version are http://homepage.mac.com/billfenner/id-guidelines/1id-guidelines-diff.html I expect to remove the Status of this document section and all of the entries inside [[..]] when it's ready to be installed as 1id-guidelines.txt. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
