I remember all the arguments about PGP vs. the RSA patent and how much time was wasted arguing about that patent and worrying about it, when a) it was never clear that it was a valid patent and b) RSA never enforced it up until the time it expired.
This is the first time I've heard someone claim that RSA "never enforced its patents"! RSA, when it owned the patents, was the poster boy for the "I own this patent and I'm going to get your money" movement - insisting that nobody, but nobody, could use RSA without a license agreement that either involved hefty payments to RSA or significant equity stakes in the company. I'm RATHER happy the patents have expired!
it came as a great surprise to me that in the neat drawings of IP headers (bits numbered marching across the page from 15 down to 0), the actual sequence of bits transferred across an Ethernet was 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 (bits counted off right-to-left, bytes counted off left-to-right).... and that for some dialects of Token Ring, it was the other way around.....
Among the attempts to give the communications world a sensible application-layer infrastructure, I count CORBA as one of the most spectacular failures - an overcomplex, underspecified monster that still has thousands of engineers trapped in its intricacies. It takes a special kind of mind to love CORBA.
I feel that the Jabber team didn't do their homework, and I am incredibly disappointed that IETF didn't have someone flag these problems. The fact that it has been so many years since they started working on this, and that they have not stumbled across this themselves does not bode well for the Jabber team.
In fact the designer of BEEP, Marshall Rose, has been active in the XMPP area (he took the minutes for the Jabber BOF in Yokohama, summer 2002). So it's not that they had nobody around with a clue - I guess they decided something else was more important.
the IETF in fact achieved consensus on an IPR policy. It was just not a policy that demanded Royalty-Free and Open Source Compatible licensing of everything.
Dream on. Verisign will sell a domain name to ANYONE. You can't get it yanked for anything connected to behaviour - unless it's selling the domain name to the trademark owner. ISPs are the ones with antispam policies.
This has been known since the beginning of networking. If you overload a resource, you back off - EXPONENTIALLY and RANDOMLY DISTRIBUTED. The more congested, the longer you back off. And you do NOT want lockstepping, so you add a random component. Do RSS servers know how to tell the clients "I'm congested"?
I will be very surprised if the W3C ever bothers to ask anyone to standardize its recommendations. If it quacks like a standard and walks like a standard, don't believe the people who call it a recommendation, a request for comments or a piece of blue cheese. The ITU standards are called "recommendations" too.
XML is a standard from the World Wide Web Consortium. Some RFCs are standards published by the Internet Engineering Task Force (IETF). Some are not. Most of the standards document protocols of some sort. Some document tools used to describe protocols, and some of these are languages (ABNF, RPSL). Some RFCs document protocols that use XML to represent their syntax. Some of these RFCs are IETF standards.
the IETF just approved a new WG whose charter says:
The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format.
The name of the group is ATOMPUB, so you see where the rest of the experience being considered comes from.
And after you've sold a frequency to a private company, good luck trying to get microbroadcasting or wide-spectrum rights - or ANY "commons" rights that were not in the original bill of sale - across the frequency band you just sold. When you sell something, you've sold it.
From RFC 1531, the IETF definition of DHCP, authored by Ralph Droms, who was then at Bucknell University:
5. Acknowledgments
Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design.
DHCP was developed in the IETF. Microsoft was an early adopter.
make sure there's at least one set of master passwords available in a safe deposit box somewhere. Instead, I keep all my data on systems that are possible to break into with a boot floppy and some imagination, and assume that my friends will help my family get the critical stuff if something happens to me. It doesn't change much - they'd still need my friends' help to figure out where the data are, so overriding the lost passwords doesn't add that much to their problems.... and the data that I lock away under PGP-style security with NO backup key is the data that I don't want ANYONE to see (or stuff I don't care enough about to worry about whether it's recovered or not). So much for an adequate level of security.
I vastly prefer other labelling schemes. draft-malamud-no-soliciting-07 has been approved by the IETF as a Proposed Standard, and allows for per-jurisdiction labelling without cluttering up my subject lines with this kind of labelling. The only good thing to be said about labelling is that lack of it can be considered prima facie evidence of bad faith...
So NOW I know why everyone's telling me that LEAP is not the end-game, and we need to move to systems based on PEAP (which is supposed to be an open standard, as opposed to LEAP which is proprietary) or some other, even newer variant. Security protocols are like windows (the physical kind). Once they're broken, duct tape is not the answer.
I believe I've read the story in one of Isaac Asimov's short story collections. A Sun-dweller is caught by a solar storm and flung into space, where he is caught by an invisible object (the Earth) and crushed against its cold surface.... the being is briefly visible on the radar screen of a passing airplaine, but is destroyed by the Earth's coldness before even the barest understanding of what the viewers see can be achieved. I thought it was a rather sad story. (and I'm sure someone else remembers the story and collection name.... I don't....)
WHOIS data should be useable for one purpose only: Getting into contact with the person or organization that owns the domain. Any amount of redirection, clearinghouses, care-of addresses and so on SHOULD be permitted - *as long as legitimate communication to the address listed gets to the domain name owner*. I've said this many times over the last 10 years, because it seems so blaringly obvious to me - but people *still* say things like "the WHOIS data must list correct address information for the owner" and think it means that it must list the street and number of the house I live in. That's JUST PLAIN WRONG. Forgive me that I shout.....
When.biz was introduced, the effect of the "alternate" roots' "biz" domain (there were multiple, conflicting ones) was absolutely nothing. Big, fat zero. The same thing will happen if ICANN chooses to introduce.xxx to the ICANN root (my prediction). These people never had a chance of influencing ICANN - if ICANN had let itself be influenced by them at all, ICANN would have been in so much trouble, its current problems would look peaceful. ICANN decides what's added to ICANN's root. Live with it.
actually a lot of the delay IS speed-of-light. I once wrote a program that sent out small packets and big packets and looked at the difference in propagation times - you could get a reasonable first-order-of-magnitude guess at the actual bitrate of the links from the variation in echo times (which is due to how long it takes to clock the packet onto the wire), and once that's out of the way, you can try to match up the delay with the distance between the sites. Turns out that for intercontinental, you have pretty good luck guessing at the length of the wire between cities.... (no, it was never released, and I don't have the code any more - three jobs ago, and in an age where 2 Mbits/sec was a high speed link....)
Slashdot Mirror
This is the first time I've heard someone claim that RSA "never enforced its patents"!
RSA, when it owned the patents, was the poster boy for the "I own this patent and I'm going to get your money" movement - insisting that nobody, but nobody, could use RSA without a license agreement that either involved hefty payments to RSA or significant equity stakes in the company.
I'm RATHER happy the patents have expired!
There's one in the Computer History Museum in San Jose. Not in working order, though....
it came as a great surprise to me that in the neat drawings of IP headers (bits numbered marching across the page from 15 down to 0), the actual sequence of bits transferred across an Ethernet was 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 (bits counted off right-to-left, bytes counted off left-to-right).... and that for some dialects of Token Ring, it was the other way around.....
What's obvious.... is not always so.
> Does the water level of your glass change when the ice melts?
Antarctica. Greenland.
Ice on land tends to run off the land when it melts.
in the dike-building industry based on sea-level change, for instance......
Among the attempts to give the communications world a sensible application-layer infrastructure, I count CORBA as one of the most spectacular failures - an overcomplex, underspecified monster that still has thousands of engineers trapped in its intricacies.
It takes a special kind of mind to love CORBA.
In fact the designer of BEEP, Marshall Rose, has been active in the XMPP area (he took the minutes for the Jabber BOF in Yokohama, summer 2002). So it's not that they had nobody around with a clue - I guess they decided something else was more important.
.... is not quite as simple as this ....
the IETF in fact achieved consensus on an IPR policy. It was just not a policy that demanded Royalty-Free and Open Source Compatible licensing of everything.
Dream on.
Verisign will sell a domain name to ANYONE. You can't get it yanked for anything connected to behaviour - unless it's selling the domain name to the trademark owner.
ISPs are the ones with antispam policies.
perhaps the virus writer thought he could collect IPO shares on the cheap?????
This has been known since the beginning of networking.
If you overload a resource, you back off - EXPONENTIALLY and RANDOMLY DISTRIBUTED. The more congested, the longer you back off. And you do NOT want lockstepping, so you add a random component.
Do RSS servers know how to tell the clients "I'm congested"?
9 AM or 9 PM?
will my daily fix disappear in 10 hours 30 minutes, or 12 hours sooner, which is..... wait, that's obvious, isn't it?
Forget that I asked, please....
I will be very surprised if the W3C ever bothers to ask anyone to standardize its recommendations.
If it quacks like a standard and walks like a standard, don't believe the people who call it a recommendation, a request for comments or a piece of blue cheese.
The ITU standards are called "recommendations" too.
XML is a standard from the World Wide Web Consortium.
Some RFCs are standards published by the Internet Engineering Task Force (IETF). Some are not.
Most of the standards document protocols of some sort. Some document tools used to describe protocols, and some of these are languages (ABNF, RPSL).
Some RFCs document protocols that use XML to represent their syntax.
Some of these RFCs are IETF standards.
the IETF just approved a new WG whose charter says:
The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format.
The name of the group is ATOMPUB, so you see where the rest of the experience being considered comes from.
And after you've sold a frequency to a private company, good luck trying to get microbroadcasting or wide-spectrum rights - or ANY "commons" rights that were not in the original bill of sale - across the frequency band you just sold.
When you sell something, you've sold it.
From RFC 1531, the IETF definition of DHCP, authored by Ralph Droms, who was then at Bucknell University:
5. Acknowledgments
Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design.
DHCP was developed in the IETF. Microsoft was an early adopter.
water has been found to be wet.
make sure there's at least one set of master passwords available in a safe deposit box somewhere.
Instead, I keep all my data on systems that are possible to break into with a boot floppy and some imagination, and assume that my friends will help my family get the critical stuff if something happens to me.
It doesn't change much - they'd still need my friends' help to figure out where the data are, so overriding the lost passwords doesn't add that much to their problems.... and the data that I lock away under PGP-style security with NO backup key is the data that I don't want ANYONE to see (or stuff I don't care enough about to worry about whether it's recovered or not).
So much for an adequate level of security.
I vastly prefer other labelling schemes.
draft-malamud-no-soliciting-07 has been approved by the IETF as a Proposed Standard, and allows for per-jurisdiction labelling without cluttering up my subject lines with this kind of labelling.
The only good thing to be said about labelling is that lack of it can be considered prima facie evidence of bad faith...
So NOW I know why everyone's telling me that LEAP is not the end-game, and we need to move to systems based on PEAP (which is supposed to be an open standard, as opposed to LEAP which is proprietary) or some other, even newer variant.
Security protocols are like windows (the physical kind). Once they're broken, duct tape is not the answer.
I believe I've read the story in one of Isaac Asimov's short story collections. ....)
A Sun-dweller is caught by a solar storm and flung into space, where he is caught by an invisible object (the Earth) and crushed against its cold surface.... the being is briefly visible on the radar screen of a passing airplaine, but is destroyed by the Earth's coldness before even the barest understanding of what the viewers see can be achieved.
I thought it was a rather sad story. (and I'm sure someone else remembers the story and collection name.... I don't
WHOIS data should be useable for one purpose only: Getting into contact with the person or organization that owns the domain.
Any amount of redirection, clearinghouses, care-of addresses and so on SHOULD be permitted - *as long as legitimate communication to the address listed gets to the domain name owner*.
I've said this many times over the last 10 years, because it seems so blaringly obvious to me - but people *still* say things like "the WHOIS data must list correct address information for the owner" and think it means that it must list the street and number of the house I live in.
That's JUST PLAIN WRONG.
Forgive me that I shout.....
When .biz was introduced, the effect of the "alternate" roots' "biz" domain (there were multiple, conflicting ones) was absolutely nothing. Big, fat zero. .xxx to the ICANN root (my prediction).
The same thing will happen if ICANN chooses to introduce
These people never had a chance of influencing ICANN - if ICANN had let itself be influenced by them at all, ICANN would have been in so much trouble, its current problems would look peaceful.
ICANN decides what's added to ICANN's root.
Live with it.
actually a lot of the delay IS speed-of-light.
I once wrote a program that sent out small packets and big packets and looked at the difference in propagation times - you could get a reasonable first-order-of-magnitude guess at the actual bitrate of the links from the variation in echo times (which is due to how long it takes to clock the packet onto the wire), and once that's out of the way, you can try to match up the delay with the distance between the sites. Turns out that for intercontinental, you have pretty good luck guessing at the length of the wire between cities....
(no, it was never released, and I don't have the code any more - three jobs ago, and in an age where 2 Mbits/sec was a high speed link....)