RE: i18n name badges
Actually, I think RFID is much more expensive than bar codes, and it's even more expensive the more you use it. With barcode, you pay once for the readers. Printing barcodes on badges doesn't cost anything. RFID tags cost money every time you make a badge, plus the readers are what, 10X the cost of a barcode reader now? RFID tags with storage are currently pretty expensive, and unnecessary, IMO. Just a unique serial number and the registration database is sufficient. I think we can make both optional. Barcode is easily optional, just don't swipe in. I think you can easily lower the range of RFID so that accidental swiping isn't likely. You can also just decline to get the barcode or RFID tag. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 4:28 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges It should be RFID, cheaper, and easier, not only for the blue sheets. The badge could be pre-configured with the data from our own IETF registration. The badge will store the names of the people who we have been talking during the week, and data like when, how much time, We can then use an inexpensive reader to get a small database out of it. Someone can complain about privacy issues, but I feel that is the same now when the blue sheet is circulated, or the attendance list is in the web site, right ? It will save a lot of time (money) to all of us, including the IETF secretariat. Regards, Jordi - Original Message - From: Rosen, Brian [EMAIL PROTECTED] To: 'JORDI PALET MARTINEZ' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 10:14 PM Subject: RE: i18n name badges Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
RE: i18n name badges
Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
RE: A modest proposal - allow the ID repository to hold xml
I think there are quite a few reasons. Mine are: 1) Ability to render in alternate ways to improve readability and accessibility 2) Ability to cross reference documents 3) More uniformity in, e.g. references Brian -Original Message- From: Paul Hoffman / IMC [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:06 PM To: Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml At 6:15 PM -0400 8/27/03, Rosen, Brian wrote: I therefore have a modest proposal: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. --Paul Hoffman, Director --Internet Mail Consortium
RE: A modest proposal - allow the ID repository to hold xml
The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. There is wide variation in the macro packages people use to create a document with nroff. Even the RFC editor doesn't try hard to get the nroff source when editing; they make their own. I'm also trying pretty hard to keep the word modest I used in the title of this thread in mind. I'd like to try one simple thing to make I-Ds easier to read and use. Brian -Original Message- From: Zefram [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:56 PM To: Rosen, Brian Cc: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Rosen, Brian wrote: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. The value in this would be that it provides everyone with the document source, suitable for generating patches for the author. This is useful, but if it's going to be allowed with XML then we should also allow it with nroff, which historically we haven't. I don't have particularly strong feelings either way, but I do think these two cases should be treated equivalently. -zefram
RE: A modest proposal - allow the ID repository to hold xml
Jari If we have xml in the archive, then there are several tools that can serve you up your choice of formats from that archive. I don't think the value of storing the html bits in the archive is all that much additional value. One could have a website that delivered such a thing without storing the html bits. Such a site would permit the hyperlinking that you are talking about. We also avoid heated discussions about what was allowable in the html, what version of which tools, etc. This is a contentious enough issue (rough consensus and running code applies, right?), and making it bigger makes it harder to reach rough consensus. Let's just do one simple thing -- allow xml, and see how it goes. Brian -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 1:28 AM To: Michael Thomas Cc: Paul Hoffman / IMC; Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Michael Thomas wrote: Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) And all of these submission formats should be allowed if and only there's a text version to go with it. --Jari
RE: A modest proposal - allow the ID repository to hold xml
Lyndon You make some good points. However, I have not proposed that we change the RFC process, and I've been very carefull to propose that we only accept xml optionally, retaining the requirement to 'send text'. I did so quite deliberately, and I'd really appreciate it if we could take this one small step, rather than changing the entire process, which has served us well for so long. We get a very large bang for such a small, incremental addition. Can we just try this step and see what happens? Brian -Original Message- From: Lyndon Nerenberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:24 AM To: Jari Arkko Cc: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml On Wed, 3 Sep 2003, Jari Arkko wrote: I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. One of the primary reasons for proposing XML as the canonical RFC format is that these other formats (ASCII text, HTML, PDF/Postscript, refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source. Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) The point of XML is that you don't have to be able to read it. Given an XML DTD for RFCs, tools can be written that express the XML in pretty much any format you like. HTML would certainly be one of those formats. (And for guys like me who live and die by grep, even *I* would buy into an xmlrfcgrep program that provided grep functionality against XML-RFC-DTD files.) And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Now that the shrapnel has stopped whizzing past my head, let me explain why. The traditional way of writing RFCs is with nroff, typically using a minimal subset of the -ms macros. In recent years Microsoft Word (along with other WYSIAWYG software) has invaded the traditional UNIX typesetting tools workspace to a certain degree (in the context of writing IETF-related documents). Regardless, other than the occasional Loonie who formats this stuff purely by hand, we are all already using markup languages to create these documents. That being the case, XML isn't a new way of writing these documents, it's just a different one. The current RFC DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't see any excuse for people not to use it. Then again, I've been using troff exclusively for 20 years now, to the point where I can _almost_ see the consistency of its syntax ... While there isn't a whole lot I *can't* accomplish in troff, my experience with using it to write I-Ds suggests that those documents are so structured that I really just want to write a simple set of macros tailored for that task. I shudder to think what the Word crowd goes through in this regard. WYS might be WYG, but the path between the two (in my very limited experience) is one whose mana will suck the very sanity from your living soul. There is no argument to be made against the suitability of XML as the canonical format for authoring RFCs and drafts. Writing the raw XML might not be pleasant, but neither is writing raw 'roff (or MS Word) for many people. Let's embrace this as an opportunity. If we can get the marketing twits to concentrate on selling GUI XML RFC authoring tools, we just might be able to distract them from contaminating the actual working groups. --lyndon [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. ___ This message was passed
RE: A modest proposal - allow the ID repository to hold xml
Jean-Jacques Is it not better to add xml incremental to text, rather than exclusive OR? If we demand that the I=D editor have a tool and use it to generate text, we open a large box of problems. What if the version of the tool the author used is different from the I-D editor? What if the xml is not well formed and the tool does something unexpected? What do we do when we upgrade the xml schema (that is, do we have to go back and edit older documents)? All of these questions would have to be answered, and answered well enough to satisfy some pretty demanding people, some of whom are pretty content with the status quo. My proposal avoids such discussions. It makes no requirements other than if xml is submitted, then it SHOULD be in conformance to 2629. I also think it is MUCH better to start with the I-D archive and not change the RFC process. Among other things, I-Ds expire. If this change doesn't work, in 6 months, we can be rid of any vestiges. RFCs don't expire (although they get obsoleted), and the time frame is much longer. Let's stick to I-Ds only, please. Brian -Original Message- From: Jean-Jacques Puig [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:47 AM To: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote: You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) May I add in the same direction ? The structure of the document allows for invoking relations between nodes, which helps for expressing elaborate search both on meta informations (WG, Author, etc.) and on content (the actual titles and text sections). You can surely look within all 'xmlly' available drafts for draft belonging to a specific WG AND referencing a list of specific docs in sections whose title contains a specific word. This would be hard to express against the txt version. And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) I wonder whether this has not already been done by zvon (http://www.zvon.org/). Concerning referencing rfcs, citation libraries from http://xml.resource.org look rather complete. Several additions to the xml cause: Edition in xml allows for good modularity, e.g. with the definition of xml entities. This is an easy way to divide work between several editors. Availability of the xml source helps for editors to welcome new contributors. What I would suggest is the following: - Authors provide draft in xml XOR txt . This allows for a test period of xml as an alternate default format; authors do not provide both, this in order to avoid incoherences. - rfc editor generates txt, ps, etc. versions. html version may only require reference to a stylesheet, though this is currently tricky because few browsers actually support xml+xsl. Newcomers to xml should be informed of the following: - xml is easy. - Grammar/spelling tools compatible with html generally work (I use ispell and aspell indifferently). - Document structure and well-formedness can be validated. - Maintaining an xml source is easy, compared to maintaining a ASCII formatted txt: this is a point authors may care about. - xml rendering generates classic formats and newers: this is what reviewers, readers care about. - xml users are not hackers, extremists or ninjas. Common sense and good pratice is the main source of xml advocacy. Also, xml is not perfect; it is only better. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
RE: A modest proposal - allow the ID repository to hold xml
Vernon Are you suggesting that we would need a new working group to allow 2629 conformant xml to be optionally submitted with text to the I-D archive? Why? I'm not proposing any new RFC. Guidelines to authors is not an RFC. 2629 is an RFC. The xml2rfc tool, which is not the only tool around, but it's a good one, puts a 70 line style header in front of the text, but then has almost no other bloat that I can see. Is that too much? I don't think there is any cruft at all in the xml described in RFC2629. Now, to the charge that this is feeping creaturism, we must admit guilt. I think there is some value in this proposal. Many seem to agree. Brian -Original Message- From: Vernon Schryver [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml From: Lyndon Nerenberg [EMAIL PROTECTED] ... [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. I don't know about shutting down the IETF, but I do know that in this century you've stated the compelling reason to run screaming from this set of proposals. Have you looked at the 250 lines of XML cruft that Microsoft thinks are required to accompany a 1 word mail message today? Have you ever glanced at the incredibly bloated and broken HTML that most HTML mark-up tools produce? Now recall the galloping freeping creaturism of the last 3 I-Ds you've read. A Turing machine with Perl-like syntax would be incomparably simpler and cleaner than the result of the 5 years work of the new working group in the new area. (What--you don't realize that a new working group would be required?) Vernon Schryver[EMAIL PROTECTED] ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
RE: ASN.1 (Re: Pretty clear ... SIP)
Good points, esp. the references to 2234. May I also point out that many SIP stacks use automatically generated parsers from the ABNF description. These have many, but not all, of the advantages claimed by ASN.1. It was a goal of the RFC3261 work to make the ABNF grammar complete enough to use a parser generator. Strict compliance to 2234 is helpful in this regard. The proof is in the pudding. Our experience with interoperability testing is quite good, and contrary to statements on this thread, most current systems interoperate with very old SIP devices. This is more true of old SIP phones than it is of old proxy servers. If you use a time line based comparison (age of spec vs interoperability results), I think you would find SIP beats the pants off of H.323, which in the first several years was dismal, but of late is pretty good. Also note that SIP is quite compressible, c.f. RFC3320, and the wireless folks, currently one of the applications most concerned with the number of bits on the wire, seem quite content with compressed SIP, and are not beating the doors down for ASN.1 encoding. This version of the ASN.1 debate at least is focusing on PER. The last one I remember was the Megaco debate, which was BER based. They lost that one; the work showed BER encoded ASN.1 was both longer and slower than text encoded. With Megaco, you have directly comparable messages. Brian -Original Message- From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 2:50 AM To: Karl Auerbach Cc: IETF Subject: ASN.1 (Re: Pretty clear ... SIP) Aah an ASN.1 firefight! It's been a LONG time since we've had one of those, but they used to be a regularly scheduled event on this list. I used to have opinions on this debate - for a trip down memory lane, check out the canonical X.400 vs SMTP debate on my website (sorry, typing offline at the moment - google will find it). One note, however: --On 25. august 2003 15:16 -0400 Dean Anderson [EMAIL PROTECTED] wrote: It is certainly true that net telephony and conferencing need extensibility - but I would suggest that the hooks for extensibility ought to be concisely defined and placed in specific parts of the protocol structures (such as the SDP part of today's call establishment protocols). I see no need to burden the entire protocol representation under a mutable layer of complexity such as ASN.1 when there is no reason that can be articulated to require such mutability. ASN.1 is not automatically extensible. You have to specify where the protocol can be extended. If you don't use extensions, it should be possible to have an ASN.1 runtime that omits the code to handle them. (One of many possible runtime optimatizations that are possible but rarely seen in practice, except with hand-coded encoders/decoders) One warning to those with long memories and strong opinions: The way one does extensibility in ASN.1 has changed greatly since the first (1984) versions of ASN.1. Lots of the hard opinions people have here are based on ASN.1(1984) experience, which was what SNMP originally used. I have had people tell me that the post-1988 versions of ASN.1 are really nice in this department, but haven't used ASN.1 seriously since approximately 1992 (when PER was just being stabilized). So I'm not qualified to say whether they are right or not. Aside on complexity: The definition of ABNF, the formal language used to define the SIP syntax, RFC 2234, is 14 pages long, and has been blasted by several people as being a too complex tool for proper protocol description. I haven't checked the pagecount of the ITU recommendations defining ASN.1 recently, but the last time I had one in hand (X.208/88), I'd estimate it as at least 10 times that number of pages. Harald ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
RE: presentation-prep as safety hazard
Well, but Most PC designs use phase lock techniques which keep external signals way below the CPU operating frequency There are legal limits for radiation; most laptops and all PDA devices are "Class B" which is a pretty low level. The real issue I suspect is that there is no practical way to test what the effect of a whole planefull of "at-the-limit" devices do to the plane's systems. It is very reasonable to design the avionics to be hardened against this sort of thing, but the older planes wouldn't have such avionics. I expect we will see some lessening of the rules as the experience and turnover of the airframes proceeds. We already have the "mobile use okay until pushback" which is a real change. Brian -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:24 PM To: RL 'Bob' Morgan; [EMAIL PROTECTED] Subject: Re: presentation-prep as safety hazard At 19:11 19/03/2001 -0800, RL 'Bob' Morgan wrote: On the plane last night, flying in to Minneapolis: "We're now starting our descent, please return your tray tables and seat backs to their upright and locked position, and turn off any electronic equipment." 2 minutes later: "People! We really need you to turn those laptops off NOW ..." note that having a PC with a 500 MHz clock means that there is an oscillator in there running at some hundreds of megahertz, attached to a nest of wires of uncertain shape. this particular setup WILL transmit energy in the radio bands below 500 MHz. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED] - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: rfc publication suggestions
I didn't mean to imply the IESG is doing something wrong deliberately. From personal experience, documents are approved by the IESG that have unresolved IANA considerations. From observation, documents are approved by the IESG that have normative reference issues. The next event is some months later, when the RFC editor picks up the document, and authors are notified of the issues. Are you suggesting that in all, or even most of the cases, authors are unaware of these issues before the RFC was approved by the IESG? Brian -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, March 12, 2001 7:18 PM To: Rosen, Brian Cc: [EMAIL PROTECTED] Subject: Re: rfc publication suggestions What happens now is silliness due to the known queue length - we put things in we know are deficient, always assuming we will have the issues resolved before it wends it's way through the queue. Where in the world do you get that idea? I spent four years on IESG and I can't recall a single instance of this happening. Seems like what we have now is a lot of uninformed speculation. Keith
RE: rfc publication suggestions
An interesting metric would be the time from the date something enters a queue to the time its status is first changed - i.e. the first time the editor looks at it. I believe that is some number of months. Once the editor picks it up, then its time in queue is more a function of outside influence (waiting for others to do something), then internal processing of the RFC editor. That's my recent experience anyway. I'd love to have a discussion of: What do we WANT the queue time to be What would we have to do to get it there I'd say that time to first action should be a couple of weeks to a month. I'd also like to see if there were some more processes we could put in place so that the text never entered the queue until things we KNOW have to be done, are actually done (like normative references, IANA considerations,). What happens now is silliness due to the known queue length - we put things in we know are deficient, always assuming we will have the issues resolved before it wends it's way through the queue. Of course, it rarely works out that way, and instead the RFC editor gets to be the nagging mother to us all. Maybe we change the process so that a document is looked at immediately for those missing things, and put in a hold queue until they are resolved, and THEN they get into the "real" queue. How much work would it be to scan the document for the normal missing items? Could we allocate people to do that as they enter the process? Brian -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTED]] Sent: Monday, March 12, 2001 4:18 PM To: Dave Crocker Cc: Steven M. Bellovin; [EMAIL PROTECTED] Subject: Re: rfc publication suggestions At 02:16 PM 3/12/2001 +1100, Dave Crocker wrote: however the editor queue can hold things for a very long time, and not just due to waiting for an author to fix something. (gosh. we haven't discussed THIS topic in a couple of years...) the most common hold-up that I see is a wait for normative references. That held the MPLS documents up for a year. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: HTML better for small PDAs
Interestingly, 8.5 x 11 comes about because of writing, not reading. Books are smaller than 8.5 x 11. Tablets are 8.5 x 11, and typewriters copied that. Laser printers copied typewriters. Stenographers used smaller tablets because they had to hold them in their hands rather than put them on a desk. Writing on a PDA is similar. Reading is another story. Turns out that line width is not all that important. No book has 72 characters per line, and no book has fixed pitch fonts. All of that is a technology crutch, and horrible for readability. People who claim 72 character fixed pitch lines is for readers are smokin something funny. It's left-over Hollerith card, with no basis in human value. Display technology has a really annoying reality - people always want more resolution, but they pay close to nothing for it. A great many companies have imploded because they believed people will pay a significant premium for a better display (I imploded one or two myself, including a 300 dpi CRT display in '85). Just isn't so. Display technology also is not subject to Moore's law - it's currently much, much slower, and about 90% of the innovations have not turned into commercial realities. Take every announcement of new display technology with a very large dose of skepticism. The biggest problem with PDAs today is contrast ratio, and that is fixable with more brightness, but has the problem of eating batteries. You will probably see high contrast ratio, probably color, PDAs commonplace soon. They will increase resolution maybe 5% per year on average, but don't hold your breath on much more than that. I can see displays that unfold once, like a book, but the idea that to read something you will unfold, and unfold, and unfold doesn't seem like it will get very far. If you want something to be readable, use a proportional font, don't worry too much about line width, and increase your contrast ratio. With respect to this discussion, it's not ASCII that's the problem, it's the font and the fixed line width. However, if we fix that, then a we Get to fix several less important issues without any additional complexity but We get all the problems of universiality, and archival storage The solution has been obvious, but it has a cost we haven't figured out how to pay. The solution is to separate the functions of "source", "display" and "archive". Source in XML, display in a variety of formats, including fixed width, fixed pitch ASCII. Archive both the XML source and the ASCII. The cost is that to be useful, we need tools to produce nroff markup from XML source, because no one is ready to accept RFCs that can't be displayed the way we display them now, and archive them the way we archive now. Marshall's excellent work is fine for I-Ds, but it isn't enough for RFCs. We need to produce pleasing ASCII, and the tool we use for that is nroff. The tool and the DTD has to allow the overworked, and under appreciated RFC editor staff to produce at least the same quality of ASCII output as they do now, with no more than the current level of effort. New tools mean training, and that is another part of the cost. We also have to create an XML archive from the current archive. Harald's suggestion of allowing ASCII and one other file to be archived for I-Ds is a very reasonable, and very useful step. He has a really good point; if we show that we will use another format, then we can move forward. As soon as someone puts up a pleasing HTML render for the XML source, that will be my preferred way to view I-Ds. The indexing, reference, and other side effects will also be welcome. Brian -Original Message- From: Bora Akyol [mailto:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 10:27 PM To: Lyndon Nerenberg Cc: Marshall T. Rose; [EMAIL PROTECTED] Subject: Re: HTML better for small PDAs I guess I have to hold up this "letter" sized paper display and try to write on it at the same time. I'll believe it when I see it. I saw the article on this topic in MIT Tech review a few months ago, but they were saying that this technology is years ahead. In the meantime, I will keep on using my Pilot (oops Palm). Bora On Mon, 26 Feb 2001, Lyndon Nerenberg wrote: the hardware problem is the eyes and the hands. i use a pda because i can put it in my hip pocket. that's just not going to happen with a screen that half-size or full-size. You're thinking too traditionally. Displays will decouple from the processor (think Bluetooth). The "CPU" will holster on your belt, and the A4 sized thin-film display will fold up to fit in your pocket. And pixel density will increase to approach that of paper. (At 300 DPI you can shrink the font enough to get the better part of a 60x72 character page onto even todays sized PDA displays if you display in landscape.) Or maybe the technology will be
RE: 49th-IETF conf room planning
On this subject, may I suggest that we have outgrown hotel conference facilities. The place where we have outgrown them is hallways -- hotel facilities simply do not have adequate hallways to accommodate us. Much of the value of the meeting is the impromptu "BOF"s that occur in the hallways and other open areas. At this particular meeting, we compounded the problem by putting food service in the MIDDLE of the hall. We also, in virtually the same area put the registration area, causing close to illegal density of people. This is just unacceptable. Brian -Original Message- From: Lane Patterson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 13, 2000 4:30 PM To: [EMAIL PROTECTED] Subject: 49th-IETF conf room planning This has likely been proposed previously, but I would like to raise the topic of mapping adequate conf rooms to WGs and BOFs. I have now attended 3 WGs that had to turn away attendees due to extreme lack of space, and several others that had plenty of extra unutilized space. Would the IETF organizers consider requesting WG/BOF attendance plans upon registration? Are there other suggestions for improvement in this process? Respectfully, -Lane - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: Bake-off as trademark
That gave me a lead on a better one: Network Working Group J. Postel Request for Comments: 1025 ISI September 1987 TCP AND IP BAKE OFF How about that! Brian -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]] Sent: Monday, November 06, 2000 3:59 PM To: Henning G. Schulzrinne Cc: [EMAIL PROTECTED] Subject: Re: Bake-off as trademark In message [EMAIL PROTECTED], "Henning G. Schulzrinne" writes : I've been approached regarding the use of the (claimed-to-be) trademarked term bake-off. It would be helpful if somebody can provide credible evidence that this term has been used within the technical community for many years. (In case you didn't know, http://www.bakeoff.com/ shows the non-technical use) It's used in RFC 1371, from October 1992. Of course, that RFC also says: The IAB/IETF are committed to a timely introduction of OSI into the Internet. Anyway -- I seem to recall seeing the term in "TCP/IP Protocol Transition Handbook", from circa 193, but my copy isn't conveniently accessible at the moment. --Steve Bellovin - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: Bake-off as trademark
I also looked at the references in RFC1025, and found that IEN-70 and IEN-77 are not on line. However, IEN-165 is: http://www.normos.org/ietf/ien/ien-160.txt.1 J. Postel IEN 160 ISI 7 November 1980 Internet Meeting Notes -- 7-8-9 October 1980 and states: BAKE OFF SUMMARY Dave Mills reported on the sessions for testing the fragmentation ... Brian -Original Message- From: Henning G. Schulzrinne [mailto:[EMAIL PROTECTED]] Sent: Monday, November 06, 2000 3:15 PM To: [EMAIL PROTECTED] Subject: Bake-off as trademark I've been approached regarding the use of the (claimed-to-be) trademarked term bake-off. It would be helpful if somebody can provide credible evidence that this term has been used within the technical community for many years. (In case you didn't know, http://www.bakeoff.com/ shows the non-technical use) Thank you. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
RE: An Internet Draft as reference material
Although, actually, what would *really* benefit the historians would be searchable archives of the working group mailing lists, but that's a different issue ;) Why is that? Seems to me it's part of the same issue, and technologically, whatever solution you find for one ought to be pretty close to the other, and if you do one, you should do the other. I do think that just because a I-D expires, does not mean it is unworthy of being preserved. Now the thread started with references to I-Ds. I do think such references, except when used as historical references, should be discouraged. Certainly, I would not like to see an RFC, especially a standard's track RFC, reference an I-D. Brian
