Re: Proposal for keeping "free speech" but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)
Are you going to write mailing list software an provide it free of charge to implement all of this? Jeroen Massar wrote: Anthony G. Atkielski wrote: Pekka Savola writes: Why must each and every WG member be required to filter a person's postings? Much more convenient to do so in one place. Because each and every WG member is an individual, with his own ideas of what he does or doesn't want to read, and imposing the same rules upon everyone prevents members from making their own decisions. It also imposes the decisions of a small minority upon the majority. Here goes for a try... flame me off list if required. As it is indeed quite controversial to 'block' people, maybe there can be a solution that, though it will have overhead for listadmins, it will help the process that the workinggroup is actually for in the first place. In the several messages there have been brought up a number of solutions to the problem where one or multiple entities are (deliberately) flooding/overloading the mailinglists of workinggroups and other places with off-topic messages. There seem to be a couple of solutions, amongst which: - Filtering based on source address at the receiver - Filtering based on keywords, which has really bad side-effects. - Blocking the sender at the mailinglist level. - 3683 PR for complete full blockage of posting rights. The first is reasonably fine, as you don't see the message of the entity that one finds not useful, but you might see responses of others thus this is still intrusive and you still get those messages which you wanted to filter out. The second option might filter out messages which you did want to read. Both still will get these messages in the mailinglist archive, even though there was a consensus that those messages are unwanted. The third and fourth option are pretty definitive, no more messages from that entity, but this might be seen as silencing this persons freedom of speech. My proposal to solve this issue but keeping everybody happy: Two mailinglists: @ietf.org + full.@ietf.org full.@ is completely open, anybody can post anything they want though hopefully on topic on the subject of the workinggroup and of course based on the source address having a subscription *1 full.@ is subscribed to @ thus full.wg gets everything preserving, at least parts, of the freedom of speech that is wanted and for the people who want to read a lot of mail everyday. Initially everybody who signs up to the @ list can post to it. When the consensus on the list is that a member is not participating correctly, ignoring warnings etc, like currently this member can be banned from the list for a temporary amount of time. The member can still voice his opinions on the @ list. This thus allows him to voice his concerns to the members that do want to read them. Like the current 3683 PR the ban can become effectively indefinitely for the main list, while the poster is still and always allowed on full.@. The big concern here is of course that one could say that if you get booted out of the group that your voice won't be heard as they are not reading the other list. This is of course true, but one can raise their concerns on the full list, for instance Google won't differentiate between them and there will always be folks who will listen to it and forward these concerns when they have valid argumentation. By posting 'good' messages to the full.@ list a member can also demonstrate that he is really willing to contribute instead of disrupt. One of the nicest controversies is of course what to determine good and bad, starwars as an example, how bad are the jedi and how good are the sith, it completely depends on the side you are on, nothing else. That all boils down to trust and other factors, any mailinglist admin could abuse his position to set the sender of an address to silently discard, SMTP can have a CC: in the header and mailman will not forward the message to that person and various other nice tricks. I hope the above might give a better point to discuss all this over instead of seeing replies like "that is not good" "see above" and other comments without effective constructive arguments. Greets, Jeroen *1 = to avoid the large amount of spam flowing to the various lists which nicely get blocked because of subscription regulation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Doug Royer | http://IntelliCal.com ---|- Intelligent Calendars begin:vcard fn:Doug Royer n:Royer;Doug org:IntelliCal LLC adr:;;267 Kentlands Blvd, #3041;Gaithersburg;MD;20878;USA email;internet:[EMAIL PROTECTED] title:CTO x-mozilla-html:FALSE url:http://IntelliCal.com version:2.
Re: Alternative formats for IDs
Yaakov Stein wrote: I... And please do not write any IETF documents while using a mouse from a certain proprietary company who holds dozens of patents on mouse technology. I would complain about that also, if I had to buy that mouse in order to read a free ID. More seriously, Word is the only commonly used editor with an integrated tracking mechanism. I assume that even the purists who insist on nroff occasionally write an ID with others. I personally prefer to use TeX as a typesetting format when writing on my own, but use word for IDs since I have to cooperate with co-authors. Try CVS or SVN and diff - works for everyone. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Brian E Carpenter wrote: Doug Royer wrote: ... It does no good to discuss text that almost everyone already knows has problems. ...it was created to ensure that everyone in the room is actually discussing the same thing. Yes. Perhaps something like SVN could be available. I can 'check in' versions and people could quickly diff them. This of course would make old versions of the draft available which I feel is useful when you do not remember why something is changed. I seem to recall that this list discussed if old draft versions should be removed or kept. I do not remember the results. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Dave Crocker wrote: ... To elaborate: Is is ever valid for a working group to want to post a new draft late in the game, very near -- or even during -- and IETF meeting? The answer is clearly yes, which is why working groups route around the IETF's arbitrary deadline in the manner that Ned cites. So the early deadline rule does not even fix the problem it supposedly attacks. Yes. Often people do not read the drafts until right before an IETF meeting. Most issues are raised right before an IETF meeting. I think it would be great to be able to submit fixes that will make the meeting more productive. It does no good to discuss text that almost everyone already knows has problems. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Faux Pas -- web publication in proprietary formats at ietf.org
Mohsen BANAN wrote: On Sat, 05 Nov 2005 18:59:10 +0100, Brian E Carpenter <[EMAIL PROTECTED]> said: Brian> Here's the text. You can pick up a map at the Brian> concierge desk in the Westin. I ate at Wild Brian> Garlic last night and it was excellent. Mr. Carpenter, the IETF Chair; Your restaurant recommendations, I do take seriously. The goers go, the talkers talk and the doers do. Remember! Of course many now visit the ietf.org site primarily for the restaurant guide. And now that is only available as a .ppt file. FYI: The PPT file opens just fine in OpenOffice 2.0 -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to announce a new mailing list on ietf-announce?
It is my experience that there are two basic reasons people add themselves to a new mailing list. Those what want the idea to succeed, and those that want the derail the process with their unending useless comments. I think it is important for people to be given an opportunity to succeed. On one topic that I participate in, there are people that like to criticize a document while providing no useful feedback and claiming some inspired unspoken better idea. I think that IETF mailing lists need to be able to be found and not announced until they feel they have a solid idea or draft This would mean that the IETF is a place to submit drafts and a place to connect with people that want to solve a common problem, Gray, Eric wrote: I agree with Dave. Currently it is very difficult to get in on the early stages of a BoF, even if the subject of the BoF is of critical importance to your business or job. How does one find out - prior to attending a meeting - that a mailing list has been setup? -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I'm not going to listen to this any more.
If so, please make a separate mailing list. Yakov Rekhter wrote: ADs in their deeds, or misdeeds represent not just themselves, but IESG as a whole. As such, deeds/misdeeds of ADs should be viewed as deeds/misdeeds of IESG, and not just of individual ADs. Therefore, I think it behooves IESG to resolve *in a public forum* complains about alleged misdeeds by ADs, irrespective of whether these ADs are former or not. Yakov. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SpamOps claims about Email Authentication and open relays
Dean Anderson wrote: Brian Carpenter asked that the subject be changed. I've also removed the IESG from the cc-list. Doug, you've been misled. Inline. On Wed, 22 Jun 2005, Doug Royer wrote: I have not been following this topic closely. To the point of open relays being a problem. I think that the judgment as to if open replays are a problem or not depends on which spam lists you are on. With my system and by grep-ing through my last 4 weeks of logs there were 22,870 of 26,157 spams blocked by my usage of two open relay DNS-black lists blocking them from 14,131 UNIQUE IP addresses. You cannot know from logs whether you are blocking spam or ham. You can only see that you blocked messages. Like many before you, you've been misled, but you probably feel much better thinking that you are blocking spam. Of the two of us, you would NOT HAVE A CLUE about if I can or can not read and understand my own logs :-) I have been programming, administering, and building OS for BSD and UNIX's for about 27 years. And for the last few years Linux When the logs do not tell me what I want, I modify the tool to produce the logs I want. I am sure that those 22,000+ spams were blocked by the DNS list that "says" its an open relay list by SORBS and the other one. I'm not sure which blacklists you consider being "open relay" blacklists. Which is why you HAVE NO CLUE about my system or how I CAN read my logs :-) Note that 235.245.195.212 is not allocated. This is a forged header. 66.59.238.35 isn't running an open relay. Indeed, I could not find a single open relay spam in a sample of 15 of the 605 spams I've received in the last 24 hours. But I did find forged headers pretending to be open relay. Though that is also becoming the exception. Much spam doesn't even bother with forged headers. I do NOT rely on ANY information from the content of SPAM to tell me anything. I use the getpeername() OS call to get the IP of the remote sending system - live as they send it. If it were not for open-relay DNS black lists, I could not run my company. These are probably doing you more harm than you realize. Or are you a promoter? (there are basically two kinds of users of these blacklists: The misled who don't know, and the promoters, who know and don't care) Nether, I am one that can NOT rum my business without blacklists as I would spend my time reading 26,000 spams per month and not running my business. I have no choice, I have to fitter them out. And SORBS seem to get a HUGE percentage of them. Again, this is by trial and error and I do NOT just trust them. Try FOO-list, try BAR-LIST, repeat until the percent of spam goes down. Most "open relay" blacklists are revenge lists, and while they may block some real spam [or possibly block pretend spam that they generated--they call this "mailbombing"], their purpose is revenge and extortion. This is well documented: ORBS and its successors, SORBS, Osirusoft, Monkeys.org, IMRSS. Most people "in the know" know that none of these blacklists are suitable for blocking spam, and few ISPs or professional mail staff use them. You will just wind up blocking non-spam email. Very few people use these lists. We can tell: The -ONLY- complaints I ever got I check out myself. I manually connected to those sites, and guess what - they were OPEN RELAYS! I think over the last year (estimated 300 hundred thousand blocked message to my PERSONAL email box), I only got 5 or so complaints. And ALL of them were open relays. 4 of them were hotels where people send me personal email while they traveled. And all 4 of those hotels whois contacts that I notified told me they would fix the problem of their open relay. And all 4 of them did. And the rest (just a handful or so at the most) ignored me. And only ONE complaint in the last year was email I wanted. That is almost ZERO false positives (That ONE was in fact from an open relay site). In all cases reported to me the email came from a site that was an open relay. The reason that ISP's might not use them is because they have a large variety of users some of which have local access providers that have open relays. So the ISPs would be blocking their own customers. And because large ISPs have almost on a daily occurrence one of their virtual host customers sites hacked and used to proxy spam. They would be blocking themselves. We have been blocked by these lists since 1997, and have very little problem with their "blocking". This is due to the relatively low number of "subscribers". Last month, we had just 2 issues with SORBS. Yet SORBS blocks all of our IP address space claiming it to be hijacked. Both issues were with university student-run servers (GATech and UCLA). Neither University's professionally-operated mail systems used SORBS. We had no problem getting in touch wi
Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification
I have not been following this topic closely. To the point of open relays being a problem. I think that the judgment as to if open replays are a problem or not depends on which spam lists you are on. With my system and by grep-ing through my last 4 weeks of logs there were 22,870 of 26,157 spams blocked by my usage of two open relay DNS-black lists blocking them from 14,131 UNIQUE IP addresses. 6,676 of which have no reverse-DNS. They seem to be in IP blocks of 10-12. The other 2,616 spams that were DNS-blocked were from non-open-relay lists. I still get 20-50 spams that make it to my inbox every day. The SORBS pages say they have over 3 Million such open relay or open proxy (hacked or not) sites. Spammers seem to setup open relays and use them. And as I do not think that there are 14 thousand spammers, my guess is that the spammer machines change their IP nightly or find a lot of open relays. If it were not for open-relay DNS black lists, I could not run my company. About 90% of the the spam that is in my logs seems to be from open relays. I read your paper. And FYI, I can name ONE person that is responsible for about 60% of the spam that makes it into my inbox. So it is possible that a few spammers are reading the anti-spam lists. I can not me certain that the open-relay DNS-black lists are not blocking other traffic. I only know which lists I subscribed to after trial and error and looking at the logs to see which stopped more spam. 3) Assertions and assumtions in the draft are based on spamops "lore" rather than fact. This is bad engineering. The "issue" in the draft is whether its assumptions and assertions about open relays and email authentication are based on facts, versus the opinions of zealots. Neither open relays nor email authentication has been shown to be related to spam: Neither promoting spam, nor preventing spam. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: On responsibilities
On this subject. I have seen many that are raising issues. I wanted to say that I think they are doing a great job! When I first started working with the IETF I found some of the procedures frustrating as they were poorly documented. However there have been documents released and for a volunteer organization, I find that wonderful! -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-881-0380 tel;fax:866-494-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Voting (again)
Joe Touch wrote: I wasn't advocating for more ADs, but for more 'virtual' ADs, i.e., to move the work of reviewing out of the ADs, and let the ADs distrbute the reviews and collect and interpret the results. I would agree on one point. Document reviewers seem to me would help. Most of the initial feedback (at least for my '1' case) was editorial and not technical. The technical feedback came later. So perhaps some kind of procedural reviewer would help the AD's from what might be repetitive and common feedback? When those are fixed, then the AD's read them for technical content. The AD's would not have to worry about reading a hundred or so pages more than needed. Or were my initial submission issues rare? -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Another Bogus DNS wildcard ??
If I ping an invalid host name everything points to: host152.theplanet.com (216.234.246.152) However only from some subnets on the internet and only some of the time. Is this on purpose ?? Is someone getting ready to do a DNS catch all again like (whoever it was) a few months ago ? Its really odd: foo.dom.com exists and dom.com does not exist as a host name. Yet when I ping dom.com it points to and pings the above IP. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
As there a PERSON email address at the IESG?
Each time I ask a question I get a reply saying that the 'transaction appears to have no content'. Something broken? Original Message Subject: [Inquiry #50155] AutoReply: Could a PERSON reply please. Date: Fri, 15 Apr 2005 17:15:33 -0400 From: IETF-IESG-Support via RT <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Could a PERSON reply please.", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #50155] in the queue: IETF-IESG-Support. Please include the string: [Inquiry #50155] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, [EMAIL PROTECTED] - This transaction appears to have no content -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
LinIF meeting , This Thursday 17th, at 7PM
LinIF meeting , This Thursday 17th, at 7PM Same place, 550 2nd Street, Idaho Falls. Corner of Freeman and 2nd. East entrance, 2nd floor, Room 297 -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LinIF meeting this Thursday 3rd 7PM
SORRY - wrong mailing list! Doug Royer wrote: LinIF meeting this Thursday at 7PM. Suggested Topic: How to be self funding. Location: The same meeting place. 550 2nd street, Room 297. Corner of 2nd street & Freeman Use East entrance. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
LinIF meeting this Thursday 3rd 7PM
LinIF meeting this Thursday at 7PM. Suggested Topic: How to be self funding. Location: The same meeting place. 550 2nd street, Room 297. Corner of 2nd street & Freeman Use East entrance. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
A hackers root kit - and what they did.
A hacker broke into one of my systems using a consultants weak password and installed a root kit. Fortunately they did not do much damage before being caught. I do not think they had yet hacked the root account, so the damage was minimum. For those interested, I saved a copy of all of the installation files (much of it includes source code) that he was using. They are at: http://INET-consulting.com/ROOT-INFO.tar.bz2 (1,573,286 bytes) Some files did not have source code, they are compiled programs. (So you might NOT want to run time!) Also is a file called WHAT-HE-DID.txt that is a copy of the .bash_history file he had left behind. My guess is that he did not have that much experience as he failed to remove log and history files. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-4638 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: "Principles" of "Spam-abatement"
Dean Anderson wrote (in part): c) Work out what to do about relays and proxies, again to prevent man-in-the-middle DoS more than anything else. One site should not be able to generate mail that it "forwards" with fictitious headers and evil content so that it appears to come from some hapless but innocent network. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Sounds like his first point - fix it so they are checkable. If I am going to relay for X number of domains, it seems reasonable that we share some kind of shared key or password so they the headers they pass me can be verified. Most complaints/bounces that are automatically generated by antivirus software or reported by humans (I've read plenty of both:-( are hopeless and de facto useless without several rounds of communications, and sometimes not even then: the humans don't even know what a mail header IS and often have no way of knowing or suspecting that the From address is bogus or sending in the real header so it can be parsed by the SP postmaster. Antivirus software developers should know better (damn it!) but even THEY don't bother to parse the header or include the header in the stupid bounces they generate, or validate any sort of correspondance between originating host and From address. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. There is (1.0) legal spam and (2.0) illegal spam. Illegal spam can be (2.1) advertisements or (2.2) viruses. (1.0) Is most often traceable using the headers and content. This is getting easier to stop and there can be things done to make it easier - a computer parseable unsubscribe link and a standard protocol to unsubscribe. (2.1) Often is traceable by the content, and almost never by the headers. Content filters and blacklists of some kind can catch these and throw them in the trash or hang-up when the content matches a URL that somehow blacklisted. (2.2) Is for a virus scanner to catch and is almost never traceable. There are things the IETF can do to help with the spam problem (1.0). -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Apology Re: Principles of Spam-abatement
Ed Gerck wrote: What interests the IETF are technical spam solutions, for example, that would prevent email that comes from unidentifiable or rogue senders/MTAs to be ever received. Not because spam is detected as such but because untrusted, unidentifiable or rogue senders/MTAs are detected. Yeah, this would still leave room for trusted and identifiable senders/MTAs to send spam messages. But such spammers are no longer a hidden target. And it would be a lot harder for someone to send spam on behalf of you. Yes! I agree that the IETF can not stop spam. A very reasonable goal would be to stop or make very unlikely, or difficult to send forged spam. Or at least make it detectable early in the process of accepting email and hang up on the spammer. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Ham-Linux] Be careful what you say]
SORRY - I sent it to the wrong list! -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
[Fwd: [Ham-Linux] Be careful what you say]
http://www.infoworld.com/article/04/02/17/HNlindash_1.html ___ Ham-Linux mailing list [EMAIL PROTECTED] http://mailman.qth.net/mailman/listinfo/ham-linux -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Jabber at IETF-59
He is looking for instructions. Marshall Rose wrote: Will there be any jabbering at IETF-59? There is absolutely no information to be found anywhere, and connecting to conference.ietf.jabber.com (which was the server of choice at past meetings IIRC) room "plenary" doesn't produce results of any kind, not even a timeout, for my client. well, i'm in several rooms right now... they all appear to be working... Using which server? -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Jabber at IETF-59
I used this setup, everything still seems to work I just sent a "TEST" message to the CALSCH room and it seems to take it. It says in part: "IETF text conferencing now has a permanent home. ..." http://xmpp.org/ietf-chat.html Iljitsch van Beijnum wrote: Will there be any jabbering at IETF-59? There is absolutely no information to be found anywhere, and connecting to conference.ietf.jabber.com (which was the server of choice at past meetings IIRC) room "plenary" doesn't produce results of any kind, not even a timeout, for my client. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: How TO Filter Spam
Iljitsch van Beijnum wrote: If you reject the message during the SMTP session you don't need to generate a bounce message, the other side will do this. So the bandwidth waste is the same in both cases. Not only that, bulk spammers (hacked or not) keep it in their queue and not yours when it is not delivered. They might retry later, however they do that anyway. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug | Fax:(866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: need help from the ietf list...PKI
Masataka Ohta wrote: Doug Royer; I agree. With my mortgage customers (MISMO.org related) I have argued that private certs signed by their business partner is better than a cert issued by a well known cert company. Anyone can buy a cert from the well known company. As long as the cert company is a bank, you deposit money to the bank, the bank issues a cert for the amount of the money and your bank account is checked and reduced at the time the cert is used, there is no problem to use the bank as a well known cert company. The usage is not for money transfer, it is for document transfer. So long term certs with CRL's is still needed. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re:need help from the ietf list...PKI
I agree. With my mortgage customers (MISMO.org related) I have argued that private certs signed by their business partner is better than a cert issued by a well known cert company. Anyone can buy a cert from the well known company. A cert signed by your business partner can not be bought from any vendor. And if managed correctly they can add/delete employees and application certs real time. However, PKI does not help e-commerce or financial transactions, as discussed in my recent paper: "Meaninglessness of Public Key Cryptography for Authentication on Consumable Credential" (presented in Japan in Japanese): Abstract: For electric transactions, the essential benefit of public key cryptography over shared key cryptography is that it is not necessary to communicate with Certificate Authority on each transaction. However, it is meaningless to use public key cryptography for authentication on consumable credentials, such as authentication of remaining credential in account for electric payment, as fraud with tremendous damage is easily performed, unless communication with authorities to manage the account decrease remaining credential is required on each transaction. The problem of PKI without realtime management of remaining credential is that an attacker can use 1K USD worth of certs from 1000 different locations for 1000 seconds 1000 times a second, total amount of damage of which is 1T USD. Credential can be created only with direct communication. Masataka Ohta -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Tag, You're It!
Stephen Sprunk wrote: Thus spake "John Stracke" <[EMAIL PROTECTED]> Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. We're never going to get widespread use of signed email as long as we have pieces of mail infrastructure munging messages to make signatures useless. Signed email already gets mangled by the ietf mail servers (AFAICT), so what's one more bad idea in the mix? Mine seems to make it. This one is (at least was) signed - I hope :-) -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: arguments against NAT? - what breaks
Anthony G. Atkielski wrote: NAT has obvious disadvantages. ... ... Chat and instant messaging services will fail, and there is no way to get them to work with NAT. So far I have not been able to get chat or instant messages services to fail because of NAT. (Not that I am saying that NAT is valuable or a problem) Perhaps it is more accurate to say that some NAT implementations break chat and IM? Streaming services may fail as well. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: ... HIPPA covers _medical_ information. Email addresses are not medical information. The email address in an email message is not a medical record protected by HIPPA. Third, the email address is already being disclosed to the ISP running the relay. You keep assuming things and then declaring them as reasons for it to be a non-issue. Your assumptions about my implementation, my customer requirements, regulatory rulings relatedto HIPPA as it effects the customers license to practice, and my email routing are not true. The relevant privacy law involving email is the ECPA, not HIPPA. Verisign is prevented from disclosing the contents of any email, as is the ISP. Quite obviously, Verisign is not improperly disclosing any information. Contrary assertions are FUD Name one good reason to run a bogus SMTP server that always rejects email if it is not their intention to use the data? Why would anyone accept connections on the SMTP port at all if not to use the data? There are only two reasons that I can think of; (1) when they experimented they found that they caused email to back up one sending systems when sent to bogus hosts and/or (2) they want the sender email address. Item (1) means they did find that what they were doing broke things and they attempted to fix it. And (2) may be FUD, but there is NO law that keeps them from collecting the sender email address. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: On Mon, 22 Sep 2003, Doug Royer wrote: You do not seem to be getting the message the MTA and MUA MAY be the same program. So NOT true. I do. Even in the same program, they are different functions. The MTA should return a bounce. You should always get a bounce, in response to an error. You should never get "no such domain" in response to typing in an email address to an MUA. No bounce - it was never sent becuse the MUA checked first to see if the target domain even existed priror to sending the email. This isn't broken. You won't send any messages because you won't get to the "data" command. You will get an SMTP error code. The message is never delivered to Verisign. The fact that a 3rd party knows (or can tell) that user X tried to send email to user Y can be a violation of HIPPA security. The 3rd pary *is* verisign. And it is free to change its policy at any time and harvist those addresses. No. Because the 3rd party didn't know that X tried to send mail to Y. The domain doesn't exist, so Y's identity has not been revealed. Only non-registered domains go to Verisign. The HIPPA argument doesn't fly at all. However, Verisign is also subject to the ECPA, and may not disclose the contents email, any more than any other communications providers can. No confidentiality (HIPPA or otherwise) is broken. I'm not sure if you are ignorant of HIPPA, the ECPA, or just fear-mongering. I guess all those people who used to say there were no laws on the internet must now be thinking "well, there ought to be". Well, they're in luck. It just happens there are laws already. You reall do not have a clue about HIPPA regulations. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote >>> As was pointed out, some servers will give up right away. In either case, >>> the user should get a bounce, and can follow the instructions as to >>> whether the delivery will be retried or not >>> >> No. On once case your get a "no such host" error and never send the >> email in the first place and the other case gets a bounce. Not the same >> thing.You don't seem to understand how mail works. In both cases you get a >> bounce. In neither case is a message sent. You do not seem to be getting the message the MTA and MUA MAY be the same program. So NOT true. This isn't broken. You won't send any messages because you won't get to the "data" command. You will get an SMTP error code. The message is never delivered to Verisign. The fact that a 3rd party knows (or can tell) that user X tried to send email to user Y can be a violation of HIPPA security. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: On Sun, 21 Sep 2003 [EMAIL PROTECTED] wrote: On Sun, 21 Sep 2003 16:00:47 EDT, Dean Anderson <[EMAIL PROTECTED]> said: It never sends the email in either case. In the first case, it will say no such host, and return an error to the user. In the second case, it will attempt to connect to 64.94.110.11 and will get an error, which will be returned to the MUA. So if a domain gets shelved by accident, as happened to one NANOG poster this weekend, all their mail gets sucked up and handed a 5xx error by the Verisign server and bounced, rather than getting hit with a 4xx and retried for a few days. As was pointed out, some servers will give up right away. In either case, the user should get a bounce, and can follow the instructions as to whether the delivery will be retried or not. No. On once case your get a "no such host" error and never send the email in the first place and the other case gets a bounce. Not the same thing. I manage a site that sends mortgage documents. It NEEDS to be sure that the destination is valid before sending confidential information. So the first time a new e-mail address is allowed to send the very sensitive information to a new email address it looks up the host and submits the initial message itself. So unless I want to parse every possible error text the bogus verisign SMTP server may say, I had to hack the code so that it knows that the IP address provided by Verisign means no such host and never sends the confidential information to a site that may be using the information in a way that is in conflict with the senders confidentially requirements. Same with health / HIPPA issues. Saying I'll take your email and bounce it back is not the same as saying "hey bozo, you are trying to send to a bogus host name". The email may be encrypted, however that is not sufficient for some usage's. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: On Sat, 20 Sep 2003, Doug Royer wrote: RFC 2821 (proposed standard) sheds some light on that: (This isn't a replacement to STD0010, but reveals the disagreement on the roles of MTAs and MUAs) Your quote talks about conventions that may be used. It does not support your view that the MUA and MTA have to be separate pieces of code. If they aren't separate pieces of code, how is it that their functions will be separated? The RFC does not say they must be separate programs. It talks about separate functions at the conceptual level. But assuming an MTA is bundled together with an MUA, the MUA function must hand the message to the MTA function for routing. The function of an MTA is still to return a bounce. So even if you were right, it busts the MTA: Prior to the change, the MTA would say "NO SUCH HOST" and never send the email (and my MTA was built into my MUA). Now the MTA gets the 64.94.110.11 address and sends the email to the non existent domain. Only for the same MTA to later get a bounced email that it has to make available to the MUA. And I hope this will be my last email on this subject as this is not the list for this debate. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: On Thu, 18 Sep 2003, Doug Royer wrote: No, its not valid for a mail client to make direct connections. Can you site any RFC that says that? RFC 2821 (proposed standard) sheds some light on that: (This isn't a replacement to STD0010, but reveals the disagreement on the roles of MTAs and MUAs) Your quote talks about conventions that may be used. It does not support your view that the MUA and MTA have to be separate pieces of code. And what your ISP does for your does not have to be what other ISPs do for their customers. 2.3.3 Mail Agents and Message Stores Additional mail system terminology became common after RFC 821 was published and, where convenient, is used in this specification. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
No, its not valid for a mail client to make direct connections. Can you site any RFC that says that? There are many ISPs that block this. Are they doing something wrong? Orthogonal and unrelated. Mail clients are supposed to connect to their configured mail relays, which has the responsibility to route mail. Says who? Your attempt to reinterpret the mail specs in order to apologize for VeriSign's fraud and unfair business practice is not in the least bit persuasive. What is not persuasive is the attempts to claim they did anything wrong. Breaking existing applications like MUA's (and your ISP's relays) is wrong. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Dean Anderson wrote: It did that if you sent to any other toplevel domain that had wildcards, and others do. The behavior hasn't changed. Your mail client was making a false assumption. That is a bug in the software. The mail client shouldn't be looking up domains. It should be sending it to the relay. There is no rule that says that my smart MUA can not deliver email itself. Not a bug. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: [Asrg] Verisign: All Your ...
Before the change if I email [EMAIL PROTECTED], the email tool would tell me immedatally that no such host exists. Now, it unconditionally sends the email, then later bounces. This is a HUGE difference in behaviour. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Spammers using IETF meeting attendance lists
Yes. However being the subject if a conspiracy theory on another IETF WG I thought it would be fun to make this guess. :-) Jim Sermersheim wrote: Or the spammer just went here > http://www.ietf.org/proceedings/03mar/atts7.html >>> [EMAIL PROTECTED] 9/9/03 10:48:24 AM >>> It means that at least one person that processed the registrations was using a windows system that is now infected. That stupid blaster virus then sent email with a forged From line as if it was sent from you, then the spammers picked up that never released email address and added it to their spam list. Makes me wonder if the virus was build by someone wanting to find a lot of valid email addresses that were not otherwise available. Graham Klyne wrote: > I've just received a spam addressed to an email address that I used > (only) for registering a past IETF meeting. I don't know what is the > current policy for releasing such email addresses. > > Just offering a datum, not making any concrete suggestions. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: Spammers using IETF meeting attendance lists
It means that at least one person that processed the registrations was using a windows system that is now infected. That stupid blaster virus then sent email with a forged From line as if it was sent from you, then the spammers picked up that never released email address and added it to their spam list. Makes me wonder if the virus was build by someone wanting to find a lot of valid email addresses that were not otherwise available. Graham Klyne wrote: I've just received a spam addressed to an email address that I used (only) for registering a past IETF meeting. I don't know what is the current policy for releasing such email addresses. Just offering a datum, not making any concrete suggestions. #g Graham Klyne [EMAIL PROTECTED] -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: A modest proposal - allow the ID repository to hold xml
Rosen, Brian wrote: The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. RFC 2223 has an nroff example, see "Appendix - RFC "nroff macros" and section "3. Format Rules" says "ms" macro package. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: IAB policy on anti-spam mechanisms?
[EMAIL PROTECTED] wrote: On Wed, 12 Mar 2003 15:37:23 MST, Doug Royer <[EMAIL PROTECTED]> said: If you are talking about TLS certs (not S/MIME certs) then the ISP can issue them to the customer directly (be a CA for connections from their customers over TLS connections). I have read that the customer can be given instructions on how to add the ISP cert as a trusted CA for that usage on M$ products. Non-scaling. The *OTHER* end of the connection won't recognize the ISP's CA, most likely. Maybe I misunderstood part of the previous e-mail ... The other end would be the ISP's customer. I was not talking about exporting the CERT to non-customers. I was talking about the ISP issuing CERTs for their customers and rejecting all others to port 25 for relaying. It allows roaming and is cheaper because for "ISP-A" from/to "ISP-A customers", you do not need to buy a cert. So if I connect to a ISP-A port 25 and use a NON-ISP-A cert then relaying is not allowed even when the cert is valid and from an otherwise trusted CA. However ISP-A's customers can now have multiple (what ever it is called in the cert) domains and they can relay ONLY with their own ISP for ISP controlled domains. And if you add authentication, now the ISP can control which user(s) can relay specific domains. And I agree with you, the big cert vendor - is not going to do that for random customers. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: IAB policy on anti-spam mechanisms?
Yes, this is true in theory, but I want to know how you're going to get VeriSign to issue you a certificate with subjectAltNames corresponding to a bunch of unrelated domains. And remember that ever time the ISP gets a new customer they have to get a new cert from VeriSign with yet another subjectAltName? This seems impractical. If you are talking about TLS certs (not S/MIME certs) then the ISP can issue them to the customer directly (be a CA for connections from their customers over TLS connections). I have read that the customer can be given instructions on how to add the ISP cert as a trusted CA for that usage on M$ products. I have no idea how to get M$ products to use that cert :-) as I do not use M$ products. I know how to do that on Unix. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: Re: CAP ABNF and external references]
[EMAIL PROTECTED] wrote: In any case CAP 1.0 09-submitted is unclear as to what it means when no latency-param is specified and that needs to be rectified before it can pass WG last call. I'll add: If LATENCY is not specified, then the initiator is indicating that any timeouts are up to the responder. > It > does not stop the responder from responding earlier > and it does not stop the responder from sending some kind > of error before the timeout, both of which terminate > the command. This case is not described in 09-submitted and I think it needs to be before this confusion can be considered resolved. Section 10.1.1 Bounded Latency covers many permuations but there is no talk of returning partial results. This needs to be covered in text in 10.1.1 where latency is covered. Sure it is: If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command (short of something like network or power falure), prior to the "LATENCY" timeout value, then the "LETENCY" time has not expired. (the above text being re-writted see separate e-mail on this list) Simply send a reply. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [Fwd: Re: CAP ABNF and external references]
[EMAIL PROTECTED] wrote: Doug noted on 12/04/2002 06:14:26 PM: > > ...However your > > new p-integer does allow for 0 which is still a non-useful value for > > LATENCY. > > I agree the zero has no meaning - I'lll fix that. So are you taking the position that NO latency-param means "Never times out"?? No. I am sayng I agree that zero has no meaning - I'll fix that. Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
OOPS!
Sorry about my posts from the calendaring working group. I mis-configured my mailer - it's fixed now. -Doug smime.p7s Description: S/MIME Cryptographic Signature
Re: 10.4 IDENTIFY Command II
[EMAIL PROTECTED] wrote: > If you determined that a hacker was attacking your system, would > you first inform them: > >> 1: Network failure >> 2: CS crash/shutdown >> 3: "Im a bad boy" >> 4: "Im not allowed to be the CFO of the company" >> 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity" >> ... Hmm, Im impressed that you alone have developed the means to make software clairvoyant and have imbued it with the ability to tell a hacker from a legitimate user who is retrying something they think should/will work. I have made no such claim. I claimed that if I detect a hacker - I am dropping the connection and I think that is good protocol practice. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: 10.4 IDENTIFY Command II
[EMAIL PROTECTED] wrote: Andrea responded on 11/18/2002 01:33:41 PM: > The more I think about it, the more I think an explicit BYE command > would be beneficial. I concur. The BEEP dropping of a session is at the transport level. CAP is at the application level so a command _is_ appropriate. After all, there may be CAP commands still in progress when the CUA decides to go away. It should do so first at the application level rather than at the transport or network levels. If the CS has commands its still processing then the BYE command should be prevented. Otherwise a nice clean disconnect can be done and BEEP shutdown done, etc. In [BEEP]: 2.3.1.3 The Close Message When a BEEP peer wants to close a channel, it sends a "close" element on channel zero, e.g., ... A BEEP peer may send a "close" message for a channel whenever all "MSG" messages it has sent on that channel have been acknowledged. (Acknowledgement consists of the first frame of a reply being received by the BEEP peer that sent the MSG "message".) ... NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel. So there can not be any outstanding commands on an open channel. You can not send CAP commands on BEEP channel zero. And you have to wait for the responder to acknowledge the close. So your above case can not happen. There was a recent post by someone saying that we should not be doing anything that increases the chattiness (my words) of the protocol - and this is one of them. As in 100% of all of the cases the over the wire sequence would be: (1) CUA: sends - BYE (2) CS: but sends - okay anyway because it is specified in CAP. (3) CUA: sends - close channel X. (4) CS: sends - okay Steps (1) and (2) are a 100% useless delay. And if there are any outstanding commands on channel X, then they MUST BE processed by the CS and the CUA MUST be ready for those replies - AFTER THE BYE. No lets not do that. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: 10.4 IDENTIFY Command II
[EMAIL PROTECTED] wrote: Doug wrote on 11/18/2002 12:26:47 PM: > > Kinda illogical to me. > > If the command succeeded then I should be allowed in. > > Where does the draft say that if it succeeds that you are not allowed in? Go reread BEEP where it talks about this apparent paradox. See Section 3.1.1 Profile Identification and Initialization. Its not 100% a 1-to-1 mappable example to CAP but its a scenario where it can occur. In any case the main topic here is the way CAP deals with failures, etc. I see that the channel can be created and the authentication to fail. But I do not see that you are 'allowed in' [to a CS]. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: CAP ABNF and external references
...However your new p-integer does allow for 0 which is still a non-useful value for LATENCY. I agree the zero has no meaning - I'lll fix that. However if a initiator wishes to wait a very long time for the responder to complete, that is up to them. It does not stop the responder from responding earlier and it does not stop the responder from sending some kind of error before the timeout, both of which terminate the command. Your example of 24 hours seems excessive to me, but I would rather not limit it in the protocol as I feel the CUA and the CS implementations can decide. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: namedroppers, continued
D. J. Bernstein wrote: Bush stuck the following note into the top of my latest message to namedroppers: ... You're perfectly aware that many senders don't read messages to the list. >... Yet - you must be reading the list or you would not have seen it. Please cry elsewhere. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: about certificate?
[EMAIL PROTECTED] wrote: > ...i configured my browser to detect ... One big commercial browser and E-Mail tool is busted and they have a bug in revocation checking. (not sure which versions) Sometimes sites forget to update their certificates. I think the reason that these bugs have existed for so long is that a higher percentage of sites are starting to use certificates.
Re: Fwd: Re: IP: Microsoft breaks Mime specification
Perhaps the thing to do is make the results of interoperability testing public - only for shipping versions of software. Developers can then develop and fix their bugs and not get bad press about not yet shipped products. And when they do ship their product it seems fair their competitors and the press can broadcast their noncompliant products. If it is a bug, they will fix it. If it is not, then they get bad press. begin:vcard n:Royer;Doug tel;pager:[EMAIL PROTECTED] tel;cell:208-520-4044 tel;fax:866-594-8574 tel;work:866-594-8574 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:INET-Consulting LLC
Re: Blue Sheet Etiquette
borderlt wrote: > ... > Is there anything official that can be done to someone who is > copying names off of a blue sheet? Perhaps, get their name and > not allow them to register for future meetings? Try to embarrass > them by publishing their name? I have already decided that if > I ever see it happen again, I am going to just snatch the blue > sheet away from the person... Easy - don't go to events where you don't want people to know. The names are available. If you don't want your name on the list of attendees - don't attend. I doubt they copied the entire list. What horrible thing do you think they were doing with your name or email address? Is the fact they knew your name offensive? Or do you think that spammers attend the IETF meeting just to get email addresses? What's the issue? -Doug begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:[EMAIL PROTECTED] title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard
Re: Last Call: Date and Time on the Internet: Timestamps to Proposed Standard
"Hollenbeck, Scott" wrote: . ... > > Yes, we should have a standard, but that standard should be usable across > the IETF. In the provreg WG, we're using XML Schema to specify a protocol > because XML and XML Schema provide needed extensibility features. I can't > use 2445-compliant date-time format because XML Schema won't accept it. Now I am confused, one of the formats in that draft is without dashes and spaces - then it is EXACTLY like RFC2445. So how can XML Schema handle them then? It looks like the draft is saying "this is the proposed standard including a version that XML can not use". So I would agree that there are different needs. That point does not seem to persuade me that a 3rd format should also be documented. > We can debate the merits (or detriments) of using non-IETF specified > technologies for IETF work, but that's not the issue at hand. The > Timestamps draft describes formats that can be used where 2445-format can't, > and at least in the case of the provreg WG that flexibility is needed. I also don't care if it is IETF or W3C work. I just don't see the need to create a proposed standard this is mostly like ISO, kind of like 2445, and you think would work with a (not yet?) recommended W3C proposal. My point is - what's the point? -Doug begin:vcard n:Royer;Doug tel;cell:208-520-4044 tel;fax:208-552-1179 tel;work:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com/People/Doug org:INET-Consulting LLC version:2.1 email;internet:[EMAIL PROTECTED] title:Chief Executive Manager adr;quoted-printable:;;1795 W. Broadway #266=0D=0A;Idaho Falls;ID;83402;USA x-mozilla-cpt:;-1 fn:Doug Royer end:vcard
Re: Last Call: Date and Time on the Internet: Timestamps to ProposedStandard
Joe Abley wrote: > > On Fri, Nov 09, 2001 at 05:16:09PM -0500, Keith Moore wrote: > > However, many events are actually specified relative to a particular > > timezone, and timezone offsets occasionally change with little advance > > warning. As such, this representation may not be sufficient for > > specifying dates and times of some kinds of events, particularly > > future events. > > > > In such cases it is necessary to include a representation of the timezone > > (not merely the GMT offset) along with the date of the event. This > > specification does not provide such a facility, and is therefore > > inappropriate for representation of (for example) events on a calendar. > > Is this not covered in section 1? > > o All times expressed have a stated relationship (offset) to > No - not at all. This is a BIG issue - if you want to understand it, go to the calsch archives. Or send email to the [EMAIL PROTECTED] mailing list. -Doug
Re: Last Call: Date and Time on the Internet: Timestamps to ProposedStandard
Why not just specify that dates/times are RFC2445 compliant? The calsch WG spent a long time debating these issues. In addition the date-time format used in RFC2445 is also ISO-8601 based. In addition the calsch WG has a plan (don't laugh too hard) for the usage of time zones. This draft only mentions they exist. Why does there need to be another date-time standard? Why did this not go through the calsch working group (at least cc the working group before final proposal?). This draft acknowledges the calsch WG, but the chairs (I called Pat) never saw this - nor did I. Was it sent and debated as assumed by reading the acknowledgements? 6. Acknowledgements ... Thanks are also due to participants of the IETF Calendaring/Scheduling working group mailing list, and participants of the time zone mailing list. The iCalendar date-time format is restricted to exactly one representation of date-time (not optional spaces, dashes, ...). There was a large debate on this before rfc2445 came out. We decided on ONE format for date time based on ISO-8601 MMDDTHHMMSS [+/- ...] If the intent is to be human readable - both loose. If the intent is to be machine readable - why another similar format? -Doug
Re: precedence field and mailing lists
> I thought I was clear about proposing that the IESG or whomever add those > nasty, evil, not entirely effective, sometimes harmful, anti-standard, > profane, deprecated, left-coast Precedence: Bulk lines in the hope of > reducing the plague of vacation noise. Then write an internet draft and drive it through the IETF processes. If people like it, they adopt it. So far I don't think that 'Precedence' is a standard. If you want it to be an IETF standard (and you are sending to the IETF list), then submit an internet draft. > Agreed; as Lloyd Wood and Keith Moore have pointed out, if people would > use vacation programs that didn't respond to Bcc's, then Precedence: bulk > would be redundant. And yes, vacation programs that reply to bcc's cannot > be relied upon to get Precedence: bulk right. Exactly why we have this process. I as a user want ALL of the senders of email (bcc'd to me and all) being notified of the fact that I am on vacation. I don't see it as a bug. I might be in the minority or you might be in the minority. Until there is a proposal - the correct people will not debate the solution. > If I've a second proposal, it would be that people who delude themselves > into thinking that talk every few months in a hotel ballroom or a mailing > list matters more than what happens in the outer of the world check their > Microsoft style provincialism--err--inward directedness for holes. If you don't like the IETF process: (1) try to change it using the rules, or (2) quit. > A third proposal is that people not send nearly 4K byte signature blocks > such as that one to 1000's of people (and 2 copies to me), particularly > in circumstances where they serve no conceivable good, except perhaps to > support by example my second proposal. (Since Mr. Royer's preceding > message did not consist mostly of cryptographic cybercrud, I assume this > was purely an accident instead of an effort to second my 2nd proposal.) Perhaps you can write a draft to include user preferences in email. In that way an MUA will not sent data you don't like. Unless of course others think of those preferences as cybercrud. :-) -Doug S/MIME Cryptographic Signature
Re: precedence field and mailing lists
> > ... > > Something can be 'standard' and never used by anyone. Something can be > > used by everyone and never a 'standard'. > > Perhaps according to the Church of De Jure Standards. Well according to those in the IETF (This mailing list you keep sending to). Did you expect the [EMAIL PROTECTED] mailing list to say everything is a standard just because someone wants it to be? When in Rome do as the Romans. When on an IETF mailing list, the language and definitions are defined in RFC's. They are (at least) Experimental, Informational, Standards Track, and Standard as defined by the IETF RFC's. > I mean AOL's protocols, applications, and other computer stuff which meet > the definition of "standard" in http://www.m-w.com/ by being "established > by authority, custom, or general consent as a model or example." I still seem to be missing your point. Is it that you wish to change the IETF to be more like the AOL chat rooms? > The consent and custom of 23,000,000 people and the authority of AOL meet > all three of those dictionary requirements. They don't and should not > meet modern IETF requirements for standards track RFCs, but I suspect that > if (perhaps a big 'if') they met technical muster, they would have been > accepted 18 or 20 years ago by the ad hoc group that preceded the IETF. Again, why are you posting to this group list if you do not respect its processes? If you are attempting to change something, then maybe I missed your proposal. -Doug S/MIME Cryptographic Signature
Re: precedence field and mailing lists
> Despite IETF snobbery, has decades of use. It has defects as > a vacation program tamer, but those would be better fixed by coming up > with a replacement than by ignoring the problem. IETF effort on that > would be better spent than on some (but not all) of the newest SMTP > elaborations. Could you please point me at the standards (or otherwise) documents that describe the semantics of 'Precedence:'? It sounds interesting but I just can't seem to find out what you mean or expect it to do. And do you happen to know the name of the standards body that approved that standard? Perhaps I can find it that way. > > > In other words, the IETF itself is not above some standads bending.. > > > > what standard are you referring to? > > How about hoping that X-Loop will be preserved by those peered mailing > lists and other gateways and so prevent loops? FYI: X- is by definition - not standard header. > ... > My point is that in rational eyes, a blessing from the ITU in Switzerland > or the IESG is neither necessary nor always sufficent to make a standard. > A standard is what http://www.m-w.com/ says, "something established by > authority, custom, or general consent as a model or example." > .. Something can be 'standard' and never used by anyone. Something can be used by everyone and never a 'standard'. However the word 'standard' does not mean 'used by a bigger number of people'. > I'd rather that AOL took outside comments on their standards, but they're > still standards. Please point me at those standards. Or did you mean undocumented protocols? Or did you mean documented and not public protocols? > no more or less than the latest embrace-and-extend brain > fart incompletely described in RFC format from the Pacific Northwest. > AOL's standards are not non-proprietary, open, or sanctioned by the IETF, > but they're as much standards as the greats on which the IETF bases its > existence. I think the standard definition of standard includes, approved, reviewed, and publicly available. -Doug
Re: Is WAP mobile Internet??
> TSIGARIDAS PANAGIOTIS wrote: > > I believe, I found part of the following text in WAP Forum's WEB-pages. > However, I think the answer -from business and technology point of view- > is simple; > > Is WAP mobile Internet ? Yes and NO > > WAP is using existing Internet standards. The WAP architecture was > designed to enable standard Internet servers to provide services to > wireless devices. In other words - a gateway? If so, then it is a gateway to non-internet devices. They are not just disconnected devices. Many people have laptops that are connected then disconnected from an ISP. The mobile phones use a different protocol suite to perform their operations. I am not saying that is bad. Just that it seems to me to they are saying that they are providing a gateway to the internet for non-internet devices. Otherwise is all they would need is a bridge or router. > In addition, when communicating with wireless devices, > WAP uses many Internet standards such as XML, UDP and IP. The WAP > wireless protocols are based on Internet standards such as HTTP and TLS > but have been optimised for the unique constraints of the wireless > environment. And much email is still sent in ASCII (IEEE I think), that does mean that all internet email systems are IEEE devices. > Internet standards such as HTML, HTTP, TLS and TCP are inefficient over > mobile networks, requiring: > ... Orthogonal to the issue here - "is it the internet"?
Re: Is WAP mobile Internet??
Keith Moore wrote: > > > Here in Japan we have 8 million non-WAP mobile internet users, > > uh, no. if you don't have IP to the phone, it's not mobile Internet. > calling it Internet is just deceptive advertising. I agree. I have cell phone with an IP address. When it is powered on I can ping it from any internet system. I can browse the internet with the help of a internet <-> WAP gateway. The two seem separate to me. -Doug
Re: Sats vs plain UMTS
Harald Tveit Alvestrand wrote: > > At 09:58 16.04.2000 +0300, Musandu wrote: > >Could hand held satelitte phones kill UMTS even before it takes root, > > as the key tools for personal high bandwidth internet access? > > at the moment I think GSM killed Iridium, so the shoe may be on the other > foot.. Not only is Iridium dead - The news said they are starting to send signals to the satellites to force them out of orbit - to splash in the ocean! -Doug
Re: recommendation against publication of draft-cerpa-necp-02.txt
Peter Deutsch in Mountain View wrote: > [in part you said] > I still object to your notion that it's not censorship since people can > always go elsewhere. Where does this lead? I see the day when people > can't publish a new directory service protocol because "The IETF has > endorsed LDAP for directory services", or would ban the publication of > an extension to DNS because "it must prevent the misuse of the protocol > in creating inappropriate services". One by one, you'd be chasing > innovation to other foums. > > "Danger, Will Robinson! Danger!" The above information is nonsense. You seem to be objecting to Keith's right to object to the draft as it is written. So using your logic (As I understand what you are saying above) - you are also guilty of censorship by not wanting Keith to object. I understand you frustration as many of us in the IETF have been frustrated from time to time. If you want to convince me and others then please ignore anything you feel is a non-technical issue. And address the technical issues. Many in the IETF *are* swayed by technical content. I am undecided on this issue and I am personally glad to see this debate. I do find it an important discussion when it remains technical. Questions I have: Does this solve a problem that is not already solved by another method? Not that it has to be unique as you point out above, but if you could compare it against other known solutions (if any) then perhaps its advantages (that I have not seen yet) could help you cause? If this were not done - what could you not do? I have worked for large corporations and I have worked on large to huge scaleability problems. Why do I want this? -Doug
Re: A thought about patents
"David L. Nicol" wrote: > > After publishing your idea somewhere, for public critique, you have > a year to file your patent application. After that it becomes a > public prior art. > > Am I wrong? Or if it is a little past a year, and you can show that you have done your best - you can also get the patent. It's not a hard set time limit. -Doug S/MIME Cryptographic Signature
Re: Privacy and IETF Document Access
Lloyd Wood wrote: > > Folks, this is just a standard feature of anonymous FTP servers. > > which shouldn't be called 'anonymous', then. > > Just because it's a standard feature doesn't make it a good > idea. Speaking of invasions of privacy, I can't find where in > Navigator to set the anonymous ftp email password; looks like it's > been inherently linked to mail identity. Building mail clients into > web browsers has subtle privacy risks. The IETF did not write Netscape, maybe you issue can go to them? >From fyi24.txt, rfc1635.txt What is Anonymous FTP? Anonymous FTP is a means by which archive sites allow general access to their archives of information. These sites create a special account called "anonymous". User "anonymous" has limited access rights to the archive host, as well as some operating restrictions. In fact, the only operations allowed are logging in using FTP, listing the contents of a limited set of directories, and retrieving files. Some sites limit the contents of a directory listing an anonymous user can see as well. Note that "anonymous" users are not usually allowed to transfer files TO the archive site, but can only retrieve files from such a site. Traditionally, this special anonymous user account accepts any string as a password, although it is common to use either the password "guest" or one's electronic mail (e-mail) address. Some archive sites now explicitly ask for the user's e-mail address and will not allow login with the "guest" password. Providing an e-mail address is a courtesy that allows archive site operators to get some idea of who is using their services.
Re: Documents need to conclude
Dennis Glatting wrote: > > Last night at the IESG's open mic at the Plenary I shared my concern > on document life cycle. I am writing to clarify my comments and offer > a suggestion I did not make at that time. >. > > Once something is committed to paper in a WG a timer > starts. The document has 24 months (6 IETF sessions) > to either be sent to the IESG for advancement or > with WG consensus the Chair petitions the AD for a > two session extension, which can be extended in the > same manner again. Otherwise the document is > withdrawn. > > I believe this rule to add something the IETF sorely needs but is > unfair to impose: a little bit of project management. It's advantage > is very low overhead. > > Comments? Vendors need to make sure the protocols they help develop work. In some areas the protocols would be simple to implement if they did not have to interoperate. And there is a very real need for vendors to ship products in that 2 year window. This means that sometimes vendors do not have the time to move as fast as as the IETF could move. This can be frustrating if your company can move faster. A solution is to write drafts yourself and submit them to the WGs, then take the input from the WG and write another. I have seen many talk of this issue. I have seen fewer propose text or some kind of draft. In IMPP (one of the WGs complained about), the input was that it has been 2 years. Well IMPP has not existed for 2 years. That persons frustration was including the time it took to move those ideas into becoming a WG. Then those pioneers who have known each other for the last 2 years (or more) assembling the WG have an idea of what they want. When the WG forms they are ready to go and get it done - if it were not for the rest of us with our own ideas. This is part of the review process. Meetings of the WGs outside of the 3 general meetings are discouraged. Slowing the progress to what can be done to 2-3 hours every 4 months for the face to face communications. Email is powerful, it can often be an endless debate that the chair NEEDS to resolve. The chairs I suspect are afraid that they will be accused of moving the WG direction for their own benefit. I would hope that we have faith in our process AND our chairs, many do not seem to have that faith. I feel that deadlines will work if the chairs can whip the process into progress. In IMPP there was a loud request from the attendees for the chairs to start cracking the whip. -Doug [EMAIL PROTECTED]
Re: Looking for client APIs to access calendar info
There is an open-source effort: > From: Eric Busboom <[EMAIL PROTECTED]> > Date: Tue, 30 Mar 1999 11:29:33 -0800 > > I have created a new mailing list for this effort: > > [EMAIL PROTECTED] > > You can subscribe to this list by sending this mail: > > To: [EMAIL PROTECTED] > Subject: subscribe libical > > I will also announce this to the k-organizer list. > > -eric. Neelima Kalidindi wrote: > > Hi All, > I'm doing a research on the availability of client APIs that can > access calendar information (using the iCal/vCal standard notations). > Specifically, I'm looking for APIs that can query if a certain user or > group of users is free at a given time or time range. I'd really > appreciate it if someone could give me any help in this regard even if > it > means direction to some source where I might find such information. > > Thanks > Neelima.
