Slashdot Mirror

Let me say this once before everyone goes nuts:

I never said that RFC == standard.

Read what I wrote. I said "well on its way." I did not say "definitely will become." Just because I did not explicitly say "but may not reach that point" doesn't mean it that isn't implied.

RFCs tended to be well documented protocols and procedures that tend to head towards standards or at least widely used methods. Most protocols never even reach this point. If a person or group writes an RFC, they believe they have something worthy of a larger audience.

And yes, I am aware of the multitude of humorous standards in there (IMPS, RFC 2795, comes instantly to mind, RFC 1097 or "subliminal telnet messaging" being an earlier one).

Still, my point in that post was that many RFCs are widely used as if they were standards even though they are not stands. Internet Relay Chat is RFC's 1459, 2810, 2811, 2812, and 2813, all marked "Experimental" or "Informational". Their headers do state they are not information standards, but this has not stopped over 10 IRC networks, dozens of client programs and tens of thousands of users from using them. Likewise, RFC 1413, a.k.a. the ident protocol, has been a proposed standard for seven years, yet is included in every UNIX-based operating system. Your secure shell products (SSH) use a protocol that has a working group, but they have not even reached the RFC point in the process!

Just because someone says something is not a standard does not mean it is not widely adopted. Personally, I want to implement RFC 2324, better known as the Hyper Text Coffee Pot Control Protocol :)

Let me say this once before everyone goes nuts:

I never said that RFC == standard.

Read what I wrote. I said "well on its way." I did not say "definitely will become." Just because I did not explicitly say "but may not reach that point" doesn't mean it that isn't implied.

RFCs tended to be well documented protocols and procedures that tend to head towards standards or at least widely used methods. Most protocols never even reach this point. If a person or group writes an RFC, they believe they have something worthy of a larger audience.

And yes, I am aware of the multitude of humorous standards in there (IMPS, RFC 2795, comes instantly to mind, RFC 1097 or "subliminal telnet messaging" being an earlier one).

Still, my point in that post was that many RFCs are widely used as if they were standards even though they are not stands. Internet Relay Chat is RFC's 1459, 2810, 2811, 2812, and 2813, all marked "Experimental" or "Informational". Their headers do state they are not information standards, but this has not stopped over 10 IRC networks, dozens of client programs and tens of thousands of users from using them. Likewise, RFC 1413, a.k.a. the ident protocol, has been a proposed standard for seven years, yet is included in every UNIX-based operating system. Your secure shell products (SSH) use a protocol that has a working group, but they have not even reached the RFC point in the process!

Just because someone says something is not a standard does not mean it is not widely adopted. Personally, I want to implement RFC 2324, better known as the Hyper Text Coffee Pot Control Protocol :)

I propose that once testing has been completed on a fully standards complient version of RFC 1149, testing on the implementation of RFC 2549, or "IP over Avian Carriers with Quality of Service", should begin. This extention of RFC 1149 adds many important features, such as quality of service, security, and traffic shaping.

I propose that once testing has been completed on a fully standards complient version of RFC 1149, testing on the implementation of RFC 2549, or "IP over Avian Carriers with Quality of Service", should begin. This extention of RFC 1149 adds many important features, such as quality of service, security, and traffic shaping.

My ex-advisor is a chair of the IETF working group researching automated intrusion detection. Currently they are developing a protocol to pass messages between network devices when a potential breach is detected. It's a really complicated field, both in terms of getting a distributed group of network devices to collaborate to decide whether or not something is a deliberate attack, and in creating a security alert protocol that can't be compromised itself.

My ex-advisor is a chair of the IETF working group researching automated intrusion detection. Currently they are developing a protocol to pass messages between network devices when a potential breach is detected. It's a really complicated field, both in terms of getting a distributed group of network devices to collaborate to decide whether or not something is a deliberate attack, and in creating a security alert protocol that can't be compromised itself.

The name of the working group, and the filenames of the drafts have ALWAYS been "secsh". On the other hand the protocol itself has always been referred to as SSH in all the documents, and still is. If you want proof check the mailing list archives or the IETF working group webpage. Check your facts before you cry wolf.

All right, this is a flame. Dareth I answer it...

ECN is *NOT* a standard, nor even standards track.

The fact ECN is written up as a request for comments document (RFC) means it *is* well on its way to becoming an Internet standard. Even the process itself of becoming an Internet standard is written up as an RFC. Look at the main web page at www.ietf.org and click on the link marked "The Internet Standards Process." Look at what is there! RFC 2026!

Many protocols in modern use never became an Internet "standard"; these include things like Mobile IP and 802.11 wireless Ethernet. Your idenfication protocol used by almost any IRC server is RFC's 1431 and 0931; they never became a standard. The number of Internet standards actually issued number less than 70. The IETF itself doesn't link to them much anymore since there is an normally an RFC representing the final form of each one.

[The] systems that you have 'problems' with are systems that support ECN, not systems that don't support ECN

Sorry! Thanks for playing. If the client says it supports ECN by flagging that fact with the bits once reserved for future use, it will not run into problems if the other side says it does not. The routers, firewalls, load balancers and/or servers on the other that do not know simply to leave those bits alone and continue normally can be faulted. The TCP protocol said those bits might be used later, but many programmers did not heed that warning. Instead, they drop packets using the once reserved bits, send TCP or ICMP reset messages, etc.

So in a way, it is the client's fault for supporing a newer extension of TCP/IP that the older one. The extension works fine -- as long as the other end still tries to establish a connection reguardless of ECN support!

The reason you have trouble with these sites is because you have a client which respects the ECN bit, and there are thousands/millions of other clients which don't, which has the effect of you never reaching the site, since you always back off in deference to those clients which don't.

Major sites must be busy to the point their links are congested, aren't they? I hope not. Read the article; the problem is routers, firewalls, and other devices seeing the bits marked "for furture use" being used, and considering packets invalid. Again, the fact that an ECN host tries contacting a host that does not support ECN is irrelevant; as long as the packets get through, the ECN-aware end will realize the other end does not, and revert to normal congestion behavior.

If no device on the other end spoke ECN, you wouldn't have this problem, as it wouldn't have any way to know to treat an ECN aware client differently than one that wasn't.

The ECN aware client is in charge, at least in the failure cases cited by the article. In most failure cases (at least those I have seen), it is the *client* requesting that the connection use ECN in the first place (although servers are welcome to as well). If after the initial handshake it discovers the remote host does not know ECN, it uses the old-style of TCP throttling behavior in response to bad packets. The ECN extension was designed to allow backwards compatibility with older clients; the people who designed it were not that foolish.

Get an education before you start posting pretending you know what you're talking about.

Is the fact I have a bachelors degree in Electrical and Computer Engineering (with honors), 99% of the work for a masters degree in the same, and the fact I was accepted to one of the top doctoral schools in the country enough education? I have spent many many years studying network protocol theory, and several years administering servers. I even wrote my own IRC client at ones point in time based off the RFC documents on it, and that protocol is hardly "experimental" anymore...

Let me just say that it is the systems that do *not* handle ECN that are at fault, not the systems that *do* support it. Read the RFC specification here here, or from your nearest RFC mirror (#2481). Note how bits marked as "presently unused" and "reserved for future use" are used for explicit congestion notification.

Any protocol implementation with a bit of sanity would know to leave reserved bits it did not how handle unchanged. Unfortunately, many systems do not do this. Some firewalls see reserved bits being used as a threat, and reset connections. Other systems have no clue how to react if a reserved bit is not the default value.

A partial list of sites I know have trouble with ECN enabled (thank goodness they are the minority of web sites out there) is below. But this is like the Y2K bug; it never really should have existed.

Sites with known ECN problems (that I've seen, anyway)

• www.zdnet.com
• www.theregister.co.uk
• www.returnbuy.com
• www.uscourts.gov (the entire tree, more or less)
• www.burstnet.net (at least I don't see their ads!)
• www.time.com
• www.latimes.com
• www.e3expo.com

(These are only sites I visit rarely, thank goodness; I typically surf another 20+ websites daily without incident)

See my earlier post in this thread.

The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.

The SIMPLE working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.

The APEX working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.

Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page for the juiciest news.

See my earlier post in this thread.

The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.

The SIMPLE working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.

The APEX working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.

Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page for the juiciest news.

The IETF is in the process of proposing not one but two standard protocols for "instant messaging" applications. (Why two? It's a long story, and it isn't over.) I recommend reviewing the charters of the APEX and SIMPLE working groups, as well as the appropriate drafts.

RFC 2778 and RFC 2779 are good background information too.

It seems to me that the direction the Jabber project should take is to consider both of these protocols to be "transports" and, er-- assimilate them. Yeah... that's the ticket.

The IETF is in the process of proposing not one but two standard protocols for "instant messaging" applications. (Why two? It's a long story, and it isn't over.) I recommend reviewing the charters of the APEX and SIMPLE working groups, as well as the appropriate drafts.

RFC 2778 and RFC 2779 are good background information too.

It seems to me that the direction the Jabber project should take is to consider both of these protocols to be "transports" and, er-- assimilate them. Yeah... that's the ticket.

If you're looking for little ASCII diagrams of the relationships between PRINCIPALs, SENDER UAs, INSTANT INBOXes etc, it's the place to be!

Interoperability and a clear migration path are part of IPv6 ( Transition Mechanisms for IPv6 Hosts and Routers, Routing Aspects Of IPv6 Transition and Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels ). As a home user you can easily join the 6bone and be part of the magic. So, anyone who wants to switch to IPv6 can do so without a lot of trouble. For more info and the site where I stole those links from check out: IPv6 site

one problem with schemes like this is that compared to IP routing, DNS is much slower, less reliable, and more prone to misconfiguration. for another approach to solving the address exhaustion problem in the context of NATs, see RFC 3056 and draft-moore-6overnat-00.txt.

Previously, we worked on a publicly available implementation of SNMPv3 (first in net-snmp and then from scratch in opensnmp, both of which are BSD copyrighted code).

My next project is targeted to large scale management of IPsec installations, the code for which should also be released to the public (though the popular FreeS/Wan code base won't accept US patches, so we'll probably be instrumenting Cerberus instead; FreeS/WAN's loss I guess, otherwise we might have implemented code for them both).

Working on projects like this is great, because it's typically in the form of "here's a hard problem", now "go solve it" without any mention of "do it this way".

Previously, we worked on a publicly available implementation of SNMPv3 (first in net-snmp and then from scratch in opensnmp, both of which are BSD copyrighted code).

My next project is targeted to large scale management of IPsec installations, the code for which should also be released to the public (though the popular FreeS/Wan code base won't accept US patches, so we'll probably be instrumenting Cerberus instead; FreeS/WAN's loss I guess, otherwise we might have implemented code for them both).

Working on projects like this is great, because it's typically in the form of "here's a hard problem", now "go solve it" without any mention of "do it this way".

The whole point of multicast is that it requires very little in terms of resources. Having a high performance computing cluster isn't going to do much if you're trying to test out multicast.

More likely, you'll want a sniffer, or else access to routers, either directly or through SNMP. Because what you're really going to want to find out is bandwidth utilization. That's where you're going to see gains going with multicast.

You should head over to IETF's website and start looking at RFCs about multicast. RFCs are usually boring to read, but very insightful.

A better question to ask the Slashdot crowd would be: "Which multicast protocol should I be using?". (FWIW, I recommend going with PIM sparse-mode. See also SSM.) In terms of apps, you haven't really told us much... Are you looking for UNIX, Mac, NT? Audio, video, text, file transfer? High bandwidth, low bandwidth, reliable transport? Without this information, the question posed is so open as to be unanswerable.

RFC 2795 (Infinite Monkey Control Protocol) is by far the best RFC I've ever read.

There is already an "Open" standard in development by the IMPP working group at IETF.

And whats more if you look at the authors on the drafts then you will clearly seem Microsoft listed.

I know a lot of people here like to bash Microsoft of keeping stuff to themselves but with IM they are playing the game (or should that be GAIM ;-)).

There is already an "Open" standard in development by the IMPP working group at IETF.

And whats more if you look at the authors on the drafts then you will clearly seem Microsoft listed.

I know a lot of people here like to bash Microsoft of keeping stuff to themselves but with IM they are playing the game (or should that be GAIM ;-)).

But RFC2026 section 10.3.1 makes it pretty clear that any conforming submissions must disclose "... the existence of any proprietary or intellectual property rights in the contribution ..."

Is this merely intellectually dishonest, or is it fraud?

But RFC2026 section 10.3.1 makes it pretty clear that any conforming submissions must disclose "... the existence of any proprietary or intellectual property rights in the contribution ..."

Is this merely intellectually dishonest, or is it fraud?

First, some of the documents that Walid submitted to the IETF working group on internationalized domain names are here and here.

Now, I won't comment on the contents of these documents with the exception that one of them was submitted to the working group after the patent was granted without any mention of the patent itself.

From the looks of things, the IETF only started publishing work on internalization of domain names in 2000, so the prior art argument looks to be moot as Walid's patent application was filed in July 1999.

I have to agree with the IETF's stance. Pushing patented technology (no matter how dubious the patent is) as a standard is akin to forcing internet users into paying a tax. I applaud the IETF in their statement; license the technology for free or we'll just use something else.

patent (noun) pronounced with a short A: A grant made by a government that confers upon the creator of an invention the sole right to make, use, and sell that invention for a set period of time.

patent (adjective) pronounced with a long A: Obvious; plain; synonym of apparent.

First, some of the documents that Walid submitted to the IETF working group on internationalized domain names are here and here.

Now, I won't comment on the contents of these documents with the exception that one of them was submitted to the working group after the patent was granted without any mention of the patent itself.

From the looks of things, the IETF only started publishing work on internalization of domain names in 2000, so the prior art argument looks to be moot as Walid's patent application was filed in July 1999.

I have to agree with the IETF's stance. Pushing patented technology (no matter how dubious the patent is) as a standard is akin to forcing internet users into paying a tax. I applaud the IETF in their statement; license the technology for free or we'll just use something else.

patent (noun) pronounced with a short A: A grant made by a government that confers upon the creator of an invention the sole right to make, use, and sell that invention for a set period of time.

patent (adjective) pronounced with a long A: Obvious; plain; synonym of apparent.

The biggest problem with multicast over the internet is that it is not supported.

If it was supported, then the biggest problem would be congestion avoidance.

The congestion avoidance algorithms built into TCP are the only saving grace for the internet backbone as it exists today. With any kind of widely deployed multicast, this becomes very critical to implement and work efficiently.

There has been some progress in this area, but it is a very difficult problem. The IETF has a working group on multicast congestion control. Its work is available here:

http://www.ietf.org/internet-drafts/draft-ietf-rmt -bb-lcc-00.txt

Georouting is going to blow for routing in some tactical situations (like jungles, mountainous terrain, and urban warfare).

I don't think there are any manet protocols that will handle networks this big. Sounds like it should stay in research labs to cook for a while longer.

What you're saying is opposite from this part of The Case for IPv6:

"IPv6 encodes IP header options in a way that streamlines the forwarding process. Optional IPv6 header information is conveyed in independent "extension headers" located after the IPv6 header and before the transport-layer header in each packet. Most IPv6 extension headers are not examined or processed by intermediate nodes (in contrast with IPv4). This enables a big improvement in the deployability of optional IPv6 features, compared to IPv4 where IP options typically cause a major performance loss for the packet at every intermediate router."

Microsoft embracing and extending Kerberos was because the Kerberos spec (RFC 1050) had an extra field specifically for people to use to send extra data. This has nothing to do with BSD vs. GPL or whatever else RMS was talking about but with the fact that the Kerberos spec had a loophole that encouraged interoperability which M$ exploited. Or is RMS suggesting that RFC's should now be GPLed?

Anyway, M$ did provide the altered specs after much community outcry.

The only reason the web page is called "secsh" is that there already exists a page called "ssh" at http://www.ietf.org/ids.by.wg/ssh.html (the Site Security Handbook, which is NOT a protocol).

http://www.ietf.org/ids.by.wg/secsh.html is the main heading for all discussions on SSH and secsh. Notice its named secsh. I'm surprised you wouldn't notice.

However, as was correctly pointed out by an anonymous poster, in a clearly more understanding manner, both the names ssh and secure shell are trademarked. Although explicly secsh is not, a strong case can be made that it is equivalent to secure shell.

Now it just sucks that english phrases that are propperly descriptive of a range of possible products can be considered commercial trademarks.

-Daniel

Ignoring the minor problem that ASN.1's binary representations are the ugliest thing since Intercal or maybe PGP and that people who try too hard to steal bits should be locked up in padded rooms, and that in spite of its ugliness it's still offers incompleteness and ambiguity, the important difference between the two standards is that ASN.1 is a top-down centrally-controlled standard where anybody who wants to define an object type has to either negotiate with a committee to get namespace or buy a hunk of private vendor namespace, while XML is decentralized and anybody can define any object type they like that doesn't start with [Xx][Mm][Ll] and propagate the definitions. The good part about centralization is that it's unambiguous, doesn't lead to conflicts, and reduces portability problems, but it's slow, cumbersome, and often not worth the bother (though the slowness and cumbersomeness does encourage you to get the design right before going through the pain of registration.) Decentralized groups who want to do reusable interoperable XML DTDs still have to negotiate namespace with each other, but you can resolve much of that with naming conventions like FooProjectWidget1 instead of just calling your object Widget1, so you only need to discuss with other FooProject makers what kinds of widgets you need.

User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; 0.8) Gecko/20010217

The Project History and Credits section of the OpenSSH website would seem to refute your assertion:

OpenSSH is a derivative of the original free ssh 1.2.12 release from Tatu Ylönen. This version was the last one which was free enough for reuse by our project. Parts of OpenSSH still bear Tatu's license which was contained in that release. This version, and earlier ones, used mathematical functions from the libgmp library. That library was also included with these early ssh versions. The libgmp library is made available under the (LGPL) Lesser GNU Public Licence, although versions of that era were under the regular (GPL) GNU Public Licence.

Rapidly after the 1.2.12 release, newer versions bore successively more restrictive licenses, even though libgmp was still included and neccesary for using the software. Earlier restrictive licenses forbade people from making a Windows or DOS version. Later licenses restricted the use of ssh in a commercial environment, instead requiring companies to buy an expensive version from Datafellows.

The original license contained the following text:

As far as I am concerned, the code I have written for this software can be used freely for any purpose. Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than "ssh" or "Secure Shell".

While I can't personally vouch for the veracity of the OpenSSH history, it and the original license not only seem to directly contradict your assertion that "you couldn't use it for commercial purposes", but also seems to imply that if a derived version of the original is compatible with the protocol description, then he has no problem with someone referring to it as "ssh" or "Secure Shell".

Also, The SSH transport and user authentication protocols have been submitted to the IETF by Ylönen himself, which I believe qualifies as "submit[ting] as an open standard". As a matter of fact, it's currently the main focus of the Secure Shell (secsh) IETF working group.

All in all, this parallels the "one click" scenario pretty closely, with the difference being that SSH was far more novel and complex an idea than "one click" shopping. If Mr Ylönen had released it as a commercial product, or even just released it under a more restrictive license, there would be no debate. As it stands, though, it reeks of dodgy business practices brought on by stockholder pressure and OpenSSH's success.

No, your understanding is wrong. The standard is called "SSH". Look at the IETF SSH Protocol Description:

Abstract

SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.

Even the standards documents are unclear on what the name of the protocol is: see the list of Internet Drafts on the IETF Secure Shell Working Group page.

IETF SECSH papers

Amazing... Some people don't read the stories or the other posts. THE PROTOCOL IS CALLED SECSH. NOT SHH.

Okay? Got it? SSH is an implementation of SecSH. OpenSSH is an implementation of SecSH. Clearly, OpenSSH is leaching off the brand and name that SSH has developed. Renaming it, as they are doing to OpenSecSH, solves all these problems, and the guy is happy with that.

• Secure Shell (secsh)

Plus it has a nice ring, almost like "sex" and "sh" put together.

All of these documents are published on the IETF website. All of these documents cite Mr. Ylonen as an author. And all of these documents describe the SSH protocol. Not the "secsh" protocol - they consistantly refer to the discussed protocol as "SSH."

It's clear that "SSH" is the common name for the protocol that OpenSSH uses. Furthermore, by putting his name on a standards document that doesn't refer to the protocol by another name, surely he's endorsing this common use of "SSH"? And surely by publishing an open standard that in itself makes no claim to the name (I don't see the documents referring to the "SSH (R)" protocol), he should be relinquishing all exclusive rights to the name as a means of describing the protocol?

I don't see how OpenSSH could be construed to be deceptive in any way. It's derived from the original SSH in accordance with it's license, and interoperates with other computers using the SSH protocol. To turn around now and claim it's trademark violation which deceives the consumer, is analogous to Microsoft saying that "Word Viewer" is a trademark violation. Actually, it's closer to the Regents of the University of California accusing FreeBSD of trademark violation.

At best, it doesn't make sense. At worse, it's a deliberate and deceitful attempt to stab the people that are using the protocol (whose name he gave his blessing!) in the back.

All of these documents are published on the IETF website. All of these documents cite Mr. Ylonen as an author. And all of these documents describe the SSH protocol. Not the "secsh" protocol - they consistantly refer to the discussed protocol as "SSH."

It's clear that "SSH" is the common name for the protocol that OpenSSH uses. Furthermore, by putting his name on a standards document that doesn't refer to the protocol by another name, surely he's endorsing this common use of "SSH"? And surely by publishing an open standard that in itself makes no claim to the name (I don't see the documents referring to the "SSH (R)" protocol), he should be relinquishing all exclusive rights to the name as a means of describing the protocol?

I don't see how OpenSSH could be construed to be deceptive in any way. It's derived from the original SSH in accordance with it's license, and interoperates with other computers using the SSH protocol. To turn around now and claim it's trademark violation which deceives the consumer, is analogous to Microsoft saying that "Word Viewer" is a trademark violation. Actually, it's closer to the Regents of the University of California accusing FreeBSD of trademark violation.

At best, it doesn't make sense. At worse, it's a deliberate and deceitful attempt to stab the people that are using the protocol (whose name he gave his blessing!) in the back.

All of these documents are published on the IETF website. All of these documents cite Mr. Ylonen as an author. And all of these documents describe the SSH protocol. Not the "secsh" protocol - they consistantly refer to the discussed protocol as "SSH."

It's clear that "SSH" is the common name for the protocol that OpenSSH uses. Furthermore, by putting his name on a standards document that doesn't refer to the protocol by another name, surely he's endorsing this common use of "SSH"? And surely by publishing an open standard that in itself makes no claim to the name (I don't see the documents referring to the "SSH (R)" protocol), he should be relinquishing all exclusive rights to the name as a means of describing the protocol?

I don't see how OpenSSH could be construed to be deceptive in any way. It's derived from the original SSH in accordance with it's license, and interoperates with other computers using the SSH protocol. To turn around now and claim it's trademark violation which deceives the consumer, is analogous to Microsoft saying that "Word Viewer" is a trademark violation. Actually, it's closer to the Regents of the University of California accusing FreeBSD of trademark violation.

At best, it doesn't make sense. At worse, it's a deliberate and deceitful attempt to stab the people that are using the protocol (whose name he gave his blessing!) in the back.

All of these documents are published on the IETF website. All of these documents cite Mr. Ylonen as an author. And all of these documents describe the SSH protocol. Not the "secsh" protocol - they consistantly refer to the discussed protocol as "SSH."

It's clear that "SSH" is the common name for the protocol that OpenSSH uses. Furthermore, by putting his name on a standards document that doesn't refer to the protocol by another name, surely he's endorsing this common use of "SSH"? And surely by publishing an open standard that in itself makes no claim to the name (I don't see the documents referring to the "SSH (R)" protocol), he should be relinquishing all exclusive rights to the name as a means of describing the protocol?

I don't see how OpenSSH could be construed to be deceptive in any way. It's derived from the original SSH in accordance with it's license, and interoperates with other computers using the SSH protocol. To turn around now and claim it's trademark violation which deceives the consumer, is analogous to Microsoft saying that "Word Viewer" is a trademark violation. Actually, it's closer to the Regents of the University of California accusing FreeBSD of trademark violation.

At best, it doesn't make sense. At worse, it's a deliberate and deceitful attempt to stab the people that are using the protocol (whose name he gave his blessing!) in the back.

This already provides a set of protocols and data formats standardized under the auspices of the IETF . There's an XML encoding under way as well as an OMG committee working on CORBA IDL.

There are already applications that know how to use these protocols/formats, including the GNOME and KDE calendar programs.

Build a "calendar server" that knows how to store appointments for a horde of users, and a "vCard" server that can accept address info for hordes of users, and use the existing standards to try to build in further sorts of useful interactions.

This would make the existing tools vastly more useful. It doesn't fundamentally matter whether this involves XML, CORBA, MySQL, or LDAP; those are all implementation details that can probably vary a whole lot without breaking the fundamental idea, which is to build standards-compliant servers.

That was the whole point to defining these calendaring and scheduling and address standards, namely to provide a standard way of doing the sorts of things that Microsoft built proprietary interfaces into Outlook for.

Evolution's calendaring facilities speak iCalendar, as will the tools that Reefknot is building. Reefknot is a toolkit client/server project that speaks iCalendar. I hear the Evolution folks are planning a calendar server as well.

I sure hope they use the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (rfc2324) for that thingy. It is an RFC in the Informational stage.

We need open standards for coffee. If you don't grasp that, go read more Multatuli.

It's... It's...

Ah, but does the internet coffee machine comply with the relevant standards?

Ah, but does the internet coffee machine comply with the relevant standards?

The working group charter is here, and there is additional information about protocol candidates available here.

The open source community needs to get with the program, read the RFC's and the Internet Drafts, and start coding.

Before it's too late.