More Vancouver Hotels
Here's another one worth checking out. Another basic-style hotel that's just a couple of blocks from the Bayshore. No idea if they have rooms available, or what they're like. I just walk past these places every day ;-) http://www.tropicanavancouver.com/ --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Hotels in YVR
On 2007-Nov-7, at 18:41 , lconroy wrote: Hi Folks, I didn't see this mentioned yet, but the overflow hotel in Vancouver (the Marriot) sold out of the its IETF room block a while ago; they DO have rooms, but it will cost you an extra 600 bucks. The Robsonstrasse shows a couple of rooms left for that week. It's not high-end, but it's close to the Westin (four blocks south). I've never stayed there so I can't comment beyond this. http://www.robsonstrassehotel.com/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Daily Dose version 2 launched
On 2007-Nov-3, at 10:02 , Harald Tveit Alvestrand wrote: Not counting pictures (I think); neither one is big by today's standards, but still... If I'm accessing those pages via GPRS (I'm on Fido in Canada) I pay five cents per kilobyte for data. So, it costs me $1.65 to load .../ tools, and $5.05 to get 'the dose' (based on your size estimates). These prices are typical of all the Canadian mobile networks. And just *try* to access a modern-day web page with graphics turned off :-( --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Daily Dose version 2 launched
Henrik, I am in complete agreement with John Klensin's three main points. For me, though, the increased size of the page isn't the problem. My issue with the new home page is that it is extremely dense visually, and therefore it takes me a long time to cognitively parse the screen in order to find what I'm looking for. The dose frame completely overwhelms the left-hand frame with the tools link that I want. There is also the expectation that visiting 'tools.ietf.org' would display the tools list. I do like what the 'dose' page presents -- it's a very useful addition -- but I think it is in the wrong location. It's my feeling that http://tools.ietf.org/ should display what is currently at http://tools.ietf.org/tools/ and the Daily Dose e moved to http://news.ietf.org/. Of course this can all be worked around with browser bookmarks, but for a newcomer visiting tools.ietf.org for the first time, I very much fear the current layout will simply drive them away when they don't see anything close to what they were expecting to find. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Aug 24, 2007, at 2:53 PM, Tony Li wrote: All practical address spaces are finite and thus must be used conservatively. Platitudes aren't particularly useful. How many bits wide is a practical? And why? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
The meeting fee is almost the single largest monetary expense for me, and it keeps going up. As an individual non-attendee, I couldn't agree more. Even though the December meeting is (literally) on my doorstep, there is no way I can justify $750 just to attend a pair of WG meetings. The IETF claims we all participate as individuals, but the entry fee pretty much wipes out the possibility of individuals attending. As the barrier to admission is raised we're simply giving the process over to the (large) corporate sector. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Nomcom06: IAB Member Candidate Feedback
On Dec 17, 2006, at 7:54 PM, Nomcom06 wrote: The NomCom requests that you provide your input as soon as possible, for full consideration, please have them in no later than the end of the day, Tuesday, January 2, 2007. Folks, you might want to consider that it's the week before Christmas. Expecting people to drop what they're doing during the week most of us are scrambling to wrap up work projects before the break, finish Christmas shopping, make travel plans, and execute those travel plans, to meet your January 2 deadline is ... optimistic? -lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Risk of Laptop Seizure by Customs or Border Patrol Officers ...
Besides, there are several ways to carry confidential info while flying. Here's an example: They'll look at your laptop, but will not bother looking at the 4GB SD card you have in your digital camera These days it's called an 'iPod'. But if you want to get past the Canada Customs high-school summer students, get everything off your camera and put it on your PDA. They will arrest you for smuggling in a (Canadian bought) camera (CAD$50) and ignore all the hot European electronics you have (CAD$2000). Trust me on this. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Chair tasks
On Jul 8, 2006, at 12:27 PM, Barry Leiba wrote: I'm not completely convinced that beer is the appropriate choice in Montreal La Fin du Monde... or anything else by Unibroue. Just don't try ordering a Molson Canadian :-P --lyndon P.S. I agree with Barry's choice ;-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)]
On Jun 25, 2006, at 1:41 PM, Stewart Bryant wrote: As an example, this .gif extracted from the Y.1711 OAM protocol would be quite difficult in ASCII. It would take a lot of words to describe, which many people would then have to transcribe to some sort of timing diagram - which then may or may not be correct. However the text in that GIF is unreadable as rendered in my mail client (MacOS Mail.app). When viewed with Preview and the Gimp, the background turns gray with white boxes behind the (still unreadable) text. This demonstrates why I was arguing for a vector format, and why I am adamantly opposed to a pre-rendered bitmap format, for diagrams. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Formatin AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
As far as I know, support for SVG or _any_ vector image format is much, much less common than for bitmap formats such as PNG or GIF. Yes, but SVG is catching up rapidly. As a W3C standard, it *will* be widely implemented. So editing bitmaps is fairly trivial with well-defined results. With vector formats, there is a very complex one-way relationship between the file and what you see on the screen so the ability to edit them requires much, much more complexity. But we are describing an *archival* format. It's not important that they be editable, it's important that they be renderable on the widest range of output devices as is possible. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in AdditiontoASCII Text' to Experimental RFC (draft-ash-alt-formats)
* Use of MHTML as the archive packaging. * Use of XHTML 1.0 as the document encoding. * Use of a standard IETF defined style sheet. * Use of PNG encoding for all images. I'm in agreement with the first three, but I disagree with using PNG for graphics. PNG is a device output format that doesn't mesh with the other three, which are media-neutral input formats. Output media properties change (rapidly) over time. PNG doesn't accommodate changing output device resolution nicely. Do you generate graphics for 72DPI? 100? 300? None of these will scale (literally or figuratively) to the 1600DPI (and beyond) devices we can expect in the foreseeable future. In this case I think SVG is a better alternative. It has the attributes of PNG (open standard, unencumbered IPR) and the added benefit of media independence. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Apr 6, 2006, at 6:37 PM, Noel Chiappa wrote: Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? On BSD and Solaris you can just pass the file descriptor from the new connection to the already running server. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
CRAMing for last call
Now that bis is close to reality, I would like to push the final version of CRAM out as well. The two documents should be able to go through together, (I hope) making life easier for the RFC editor. I have some non-substantive editorial changes that will make the document a bit easier to read, but these are not show stoppers. I think all of the last round of comments are addressed in the current draft. If not, I would like to hear from people, soon. I would also like to solicit a few additional examples from anyone who has implemented CRAM in other than IMAP. Finally, we need to address the issue of the MD5 break. I have held off from commenting on this issue until the community has seen explicit evidence of the attack, and the implications of it. At this point, I don't know if the document deserves a writeup on the attack. Theory abounds, but I haven't yet seen a practical attack that works in the general case. We should at the least make mention of what has been discussed, and point to the literature, but I don't think the document deserves to discuss all the possible attacks. This doesn't mean to discourage anyone from contributing text to the Security Considerations section (please do). The IMAP-EXT list has had recent discussion that points out the ambiguity of searching for the space (SP) separator (between the user id and the digest) as being the rightmost SP, so I will strengthen that text. Any other comments should come forth soon as I would like to run out the final draft at the end of next week (Oct. 8) if I can. Cheers, --lyndon (editor) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Fwd: [Asrg] Verisign: All Your ...
The MUA in this case is performing (incorrectly) MTA functions. That is a bug. $ sendmail -t From: lyndon To: lyndon Subject: Dean is wrong hi there . $ Say again? --lyndon The longest UNIX error code is ENAMETOOLONG.
Re: A modest proposal - allow the ID repository to hold xml
Consider the problem of answering the question Is the RFC on my screen or printer the same as your document? Was either version edited by someone or something? Then no matter what DTD verifiers the RFC Editor runs, we will have people saying RFC 98765432 says blah de blah right here on this sheet of paper because they printed it with a User Friendly XML printer that fixes spelling errors and deletes bits that infringe on Microsoft's business plans and the RIAA's intellectual property. Vernon, if you honestly believe this to be true, then the only format you could possibly advocate is printed hardcopy locked up in a vault. Even ASCII documents are subject to bit rot, be it on media, during transmission, while in memory, etc. --lyndon
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.
Re: A modest proposal - allow the ID repository to hold xml
I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Extension? existential ebulliently excellent engineering experienced eccentric --lyndon (egregious evening emoter)
Re: A modest proposal - allow the ID repository to hold xml
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.) 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.) And just to eliminate any lingering doubt, I'll note that I'm now using xml2rfc for all my current and future drafts. (There, *that* just gave several people heart attacks ;-) --lyndon
Re: gatwick - hilton info?
Arriving late Sunday (10pm arrival scheduled) at Gatwick and going from there to the Hilton Metropole. The transportation web page gives lots of hype about how convenient the hotel is to just about everything, but precious little detail. Would someone who knows this sort of thing recommend the Gatwick Express and then a taxi from Victoria Station? (I'll have luggage, so the underground isn't appealing.) Take the Gatwick Express to Victoria Stn. (30 minutes *iff* it's running on time.) If you're quick about it you should still be able to take the underground to Paddington (check at Victoria to see if it's still running when you get there). From Victoria underground, take the Circle Line westbound to Edgware Road station, which is right across the stret. --lyndon (who made the trip yesterday)
Re: gatwick - hilton info?
Express and then a taxi from Victoria Station? (I'll have luggage, so the underground isn't appealing.) Sorry, I missd the luggage bit. Yes, you'll want to take a taxi from Victoria.
Re: bandwidth (and other support) required for multicast
Oh, and of course Internet standards based players are available for all platforms, right? Yes (for a larger value of "all" than RealPlayer supports). vic/vat/rat are portable to many UNIX variants, and also run under Windows. I think that MacOS is the only orphan in this scenario, but ISTR there are protocol proxies available that will gateway to something MacOS can handle (assuming they can't directly view H.261 multicast with some other tools). --lyndon
IETF Travel Woes (was Deja Vu)
London is well known to be one of the most expensive cities in the world for hotel accommodation. It would be a bad thing if clue was excluded because of the total cost of a meeting being very high. But hopefully IETF attendies are of the mindset that can forgo the ensuite hotel room for BB accomodation or the like. London is going to be interesting as we're going to be there at the peak of the holiday season, when accomodation rates are at their highest and room availability is at its lowest. For travel planning purposes it's important to me that the location of the London meeting be announced as early as possible. I doubt very much I'll be staying in the conference hotel (or anywhere near it), which means I need to book alternate accomodation as early as possible. (BTW, if you want to reproduce the Minneapolis-in-winter experience in Europe, I highly recommend Brighton in February.) Also, to follow up on (I think it was) Melinda's comments about airfare costs, I'll note that a return ticket for Edmonton-Minneapolis (a 2.5 hour flight) was just under CAD$1700. A return ticket for Edmonton-London (about 9 hours) can be had for around CAD$900. --lyndon
Re: IETF Travel Woes (was Deja Vu)
But, if you're not going to be staying in the conference hotel, you have more options, and you can book without knowing precisely where the conference hotel is. But to do that sanely I want to be within walking distance of a tube station that's on a direct line to the conference venue, thus the need for it's location. --lyndon
Re: Deja Vu
Even with Spring in MN, this is probably still a good idea. Or New Orleans, at least it is warm and centrally located. Central to population is probably somewhere in Asia. Do I need to write an informational RFC documenting how the USA is not the centre of the universe, let alone the Internet? Sigh. --lyndon
Re: HTML better for small PDAs
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 something else. The point is that the display technology _will_ be there, and it will be there soon. (Soon enough that current PDA limitations aren't a good enough justification - IMO - for the sort of changes we're talking about making.) --lyndon
Re: guidance (re: social event politeness)
Those few of you who shrugged off a polite suggestion to join the back of the queue: we know who you are, and are prepared to identify you in front of thousands of your colleagues in the industry This is definately an RFC. We also need a BCP for where to hold conversations. (Hint: NOT in the middle of the hallways, please.)
