Slashdot Mirror

I don't understand where you're going there unless the spec allows embeded raster images?

It's straightforward to make an <img /> or <object /> element that contains raster image data. Look up the data: URL scheme.

Just to pick one out-and-out lie from the general confusion of your posting:

Excuse me, but the open-source community wrote Apache from standards they didn't write.

So, in fact, the open source folks who wrote Apache and its predecesors are the folks who wrote the standards.

So as I posted on your site, the above statment is downright slanderous, and you should retract it.

There's no need for any of this. All we have to do is make use of the security flag defined by RFC3514. See it at: http://www.faqs.org/rfcs/rfc3514.html

This has been available to us since 4/1/03, and comes to us via Steve Bellovin, a security guy of note.

In general you can think of the DARPA layers as completely pragmatic and somewhat modular. You can swap in different network modules, so long as it provides a packet based network to the internetwork layer. You can swap IPv4 with IPv6 (or even IPX. yuck) without breaking TCP and UDP (you may however break plenty of applications that run on them and make incorrect assumptions). Transport is also a block that can be replaced with compatible substitutes, but since there is very little use of anything but TCP or UDP, it's not terribly likely to happen.

With OSI/ISO on the other hand, physical and data link are heavily linked. If you want to replace the physical layer with a modem instead of ethernet, you also need to change the data link from CSMA/CD + Ethernet II framing to V.22bis (or hopefully better) + PPP. The Data Link layer is also over-populated because you almost always need more than one protocol in there (for example, with ethernet, you need both CSMA/CD signalling and Ethernet II framing to make it work). You often need to have two or more protocols in that layer in order to make it fit. On the other hand, the Session and Presentation layers are often completely unused by many protocols (like Telnet, etc), and perhaps shouldn't even exist since they're largely redundant.

The OSI protocols were highly overengineered, somewhat terrifying. A few bits of the OSI protocols still exist in internet protocols. ASN.1 is probably the most notable, since it's used in SNMP, LDAP and most anything that uses certificates with public key encryption. It's fared much better than the X.400 standard which spawned it.

Defining Ethernet and TCP/IP as layers of the OSI stack is about as correct as defining the XBox as the successor to the Playstation.

The OSI stack was a failed, over-complex set of network protocols that tried to wrest control from the established, pragmatic, but not-officially-ISO-sanctioned TCP/IP (aka DARPA) protocol suite.

The TCP/IP suite model defined four layers: Network, Internetwork, Transport, and Application. That's (for example) Ethernet, IP, TCP, and HTTP for most implementations of teh Intarweb.

The OSI _model_ (not stack) is, in fact, the seven-layer cake you mention. Over the past decade or so, networking companies have "retrofitted" the OSI model onto the de facto stack, but you'll notice that they get a little wishy-washy at Layer 1, Layer 6, and Layer 7. Guess why? Because in the OSI Stack, there were actual protocols specified for those levels.

(definitely glad I learned the networking side of CS from folks who invented it, rather than someone who learned it later, out of a book...)

The asr faq traces it to afu. Google has afu posts mentioning it going back to 1997..

This time is not a rumor!

Try it for yourself. Send a string like:

<stream:stream to='talk.google.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>

to talk.google.com, port 5222. It will respond with a valid RFC 3920 (Jabber) stream!

"Approximately 212 RFCs, or about 7% of RFCs issued so far, starting with [RFC269], contain the terms `foo', `bar', or `foobar' used as a metasyntactic variable..."

No self http://www.respect-holidays.co.uk/ > respecting Lemur would be seen doing that job. They'd have enslaved the cows by then and would have them do the driving

No self http://www.respect-holidays.co.uk/ > respecting Lemur would be seen doing that job. They'd have enslaved the cows by then and would have them do the driving

No self http://www.respect-holidays.co.uk/ > respecting Lemur would be seen doing that job. They'd have enslaved the cows by then and would have them do the driving

The generic term "TCP/IP" usually means anything and everything related to the specific protocols of TCP and IP. It can include other protocols, applications, and even the network medium.

You're forgetting the time it takes for one packet to be received by the other, processed, and sent back. That means you have to include what time you think it is so that the time server can calculate the difference in a reply back so the client can fudge the number based on the calculated time it takes for one packet to be processed and sent from the server to the client.

Of course, this gets seriously fubared when you have really high latency on only one transport (upstream or downstream)

It also doesn't take into account any drifting that might occur (ie a clock that's fast or slow) should the client be unable to contact the server.

To read more, see here.

A more accurate term is "internet technology".

A more accurate term is "internet technology".

You may want to read, How do I present a new encryption scheme in sci.crypt? from The Cryptography FAQ, page 2.

1. The term "normative" describes sections (or comments/notes) which describes behaviors and feature to which implementors must adhere
2. The term "informative" describes sections (or comments/notes) which give certain details for further knowledge and do not describe behavior to which implementors must adhere
3. The term "non-normative" describes sections (or comments/notes) which describe behaviors or features of recommendation nature or changing nature
4. The words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", "may not" and "optional" are to be interpreted as described in RFC 2119

They can not put a patent on it, as there already exists previous art RFC 3251

What? The other way around? Sorry.

What do Linux zealots care about OS X coming from BSD?
"Torvalds has also said that he would have joined the BSD effort had he known of it, rather than founding his own. But 386BSD was not shipped until early 1992, some months after the first Linux release."

The sooner we kill this ".xxx" domain idea, the better.

RFC 3675 ".sex Considered Dangerous"

There's a long discussion of why, exactly, .sex (or .xxx) TLD is a bad idea.

The first few paragraphs are worth noting in this discussion

[begin snip from rfc]
Introduction

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and the technical points of view.

2. Background

The concept of a .sex, .xxx, .adult, or similar top-level domain in which it would be mandatory to locate salacious or similar material is periodically suggested by some politicians and commentators. Other proposals have included a domain reserved exclusively for material viewed as appropriate for minors, or using IP address bits or ranges to segregate content.

In an October 1998 report accompanying the Child Online Protection Act, the House Commerce committee said,
"there are no technical barriers to creating an adult domain, and it would be very easy to block all websites within an adult domain".

The report also said that the committee was wary of regulating the computer industry and that any decision by the U.S. government "will have international consequences" [HOUSEREPORT].

[end snip from rfc]

relevent to this discussion - and apparently ignored by ICAN is RFC3675 .Sex Considered Dangerous http://www.faqs.org/rfcs/rfc3675.html The first few paragraphs are worth noting in this discussion [begin snip from rfc] Introduction Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and the technical points of view. 2. Background The concept of a .sex, .xxx, .adult, or similar top-level domain in which it would be mandatory to locate salacious or similar material is periodically suggested by some politicians and commentators. Other proposals have included a domain reserved exclusively for material viewed as appropriate for minors, or using IP address bits or ranges to segregate content. In an October 1998 report accompanying the Child Online Protection Act, the House Commerce committee said, "there are no technical barriers to creating an adult domain, and it would be very easy to block all websites within an adult domain". The report also said that the committee was wary of regulating the computer industry and that any decision by the U.S. government "will have international consequences" [HOUSEREPORT]. [end snip from rfc]

It already exists. Why aren't you using Jabber and it's XMPP standard?

There are no standardized instant message protocols

You mean like XMPP (RFC 3920), a standard based heavily on Jabber?

so a message sent using AIM cannot be received using MSN.

At first, e-mail messages sent from AOL could not be received by a user on, say, Prodigy. Then after Al Gore turned the Arpanet into the Internet, the major nationwide BBSes connected their e-mail systems. What would block them from doing the same thing with XMPP, other than possibly advertisement revenue?

The inevitable smart-ass question of "Oh, but that electricity has to come from somewhere!!".

Consider this:
Energy content of gasoline: ~45 MJ/kg
Density of gasoline: 737 kg/m3
1 cubic meter = 264.172051 gallons, equals 2.79 MJ/gallon.

Now 1 kWh is exactly 3.6 MJ. Electricity costs (let's exaggerate) 30 cents per kWh.

What do you pay for gas?

Now add to that the facts that:
1) It is easier to clean up a handfull of power-plants than a millions cars distributed over the whole country.

2) Electricity doesn't have to come from fossil fuel sources

3) Even if it does, power plants still produce energy more efficiently than an automobile engine.

...until someone implements RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Wasn't the FBI already convincing network equipment manufactures like Cisco to implement RFC 3924 - Cisco Architecture for Lawful Intercept in IP Networks into their production? I think they've been working on this for a while. Perhaps the FCC ruling is the next step in order to get the snoop-enhance boxes into the internet infrastructure.

You should set up reverse DNS properly so that a reverse lookup on your mailservers IP address resolves back to its proper hostname.

Like this:
In the forward zone :

domain.com. IN MX 10 mail.domain.com.
mail.domain.com. IN A 111.1.2.123

In the reverse zone :

123.2.1.111.in-addr.arpa. IN PTR mail.domain.com.

You are not currently set up like that, and that *will* cause many mailservers to flag your mails as spam.

You may also have another problem (I have not checked, but I see it often enough to assume you probably have this problem as well).
Qouting RFC 2821 , section 3.6 ( http://www.faqs.org/rfcs/rfc2821.html ) :

"The domain name given in the EHLO command MUST BE either a primary
            host name (a domain name that resolves to an A RR) or, if the host
            has no name, an address literal as described in section 4.1.1.1."

Also, many servers will reject (or flag as spam) mail from servers that attempt to use pipelining without first querying the recipient server for that capability.

Come on guys, their server is actually a toaster. What do you expect? I think they still use HTCPCP, too.

[request]
Can we get an "auto-coral-cache" feature implemented on /.?
[/request]

It's standard and fairly simple. You can read about it here

As to why UDP is used, has nothing to do with "faster". The protocol is designed to use UDP, because it's connectionless, it has lower latency, and the TCP connection encapsulates a lot of the properites that NTP measures to correct for latency and transmission delay. If a packet gets dropped via UDP, NTP can compensate for that, with TCP it's much harder. If a packet gets dropped, retransmitting the same one again is stupid (that's what TCP would do), you should transmit a new one with a new timestamp (you can do this via UDP).

Kirby

As well as the Evil bit in the TCP header (for viruses etc), perhaps we could introduce a morality value as well, so that only highly moral traffic, for example, could enter or leave my site.

Dumbass, we have more guns per capita than you rednecks (supposedly 3x more). A significant percentage of canadians have handled a firearm before they get their drivers license (I recall its about about 40%, but I cant find a source to back it up).

http://www.saf.org/LawReviews/Cukier1.htm
http://www.faqs.org/faqs/talk-politics-guns/canadi an-faq/

http://www.faqs.org/rfcs/rfc2177.html

Slowly gaining support amongst client applications. It's a pity IMAP is just complex enough that no clients really support it as well as they could (especially offline mode), but it's pretty nice still.

Um, by reading the RFC?

Yes, the "evil" bit. Something along the lines of RFC 3514.

giyf.

http://www.faqs.org/rfcs/rfc3514.html

Yeah and there's no such thing as RFC 1738 - Uniform Resource Locators (URL) either, right?

/me clues a.c.

"A google for "cookie exploits", "cookie migration" and even a browse of IE "domain" bugs shows this to be true."

I was speaking of the way cookies are meant to function, as per RFC 2109, 'HTTP State Management Mechanism'. Buggy clients 'historically' get fixed (slowly, if they were written by Microsoft). The only cross-client behaviours developers can count on are those set forth in the RFC.

"Really? Some years ago I noticed that the FriendsReunited.co.uk website set a cookie after I'd logged in, along the lines of "confirmeduser=23959". What happened if I modified the cookie? Yep, you guessed it... ability to modify somebody elses details."

I submit that any web developer stupid enough to handle authentication in that way needs to do a lot more than be a little more careful. Whoever wrote that site did not understand their own medium. Rule number one - treat any data from the client as tainted. Session cookies should never contain references to 'real' account numbers, and should usually be hashed with something unique to a particular client, like an IP address. It's pretty straightforward to defeat session hijacking for all practical purposes, if you know what you're doing.

"If the medium is stateless there is no solution. You mean 'as a lazy developer, cookies work most of the time'?"

Oh, come on, no need to be uncivil - of course there are solutions to maintaining state during a session. Cookies can store session IDs, URLs can have them attached... If you don't like either of those methods, there's always clock skew analysis or dynamic vhosts.

"I'm guessing you claim cookies to be 'good' because your development environment/web-server is not configured to allow anything else? Why not just append a '&sessionid=[big binary data]' to all your page links? I'm guessing that, despite being a 'web developer' you are not given the ability to do so"

You guessed wrong, and your inadequacies are showing :) Flaming egos damage credibility - but thanks for the laugh, anyway.

... be using some kind of synchronization protocol like NTP http://www.faqs.org/rfcs/rfc1305.html ? All you have to do is update the server, and the clients will follow pick up the changes.

This is no where as complex as the y2k problem.

That said, I'm rather intrigued by the notion of XRC, especially since it's cross-platform.

There was something about replacing boring, repetitive and brittle code generation with data wherever possible; it seems silly that the wx folks were the first to do this. It expresses constructed GUIs in data form, then lets the program put in hooks and callbacks. I'm told that newer versions of Glade can do the same.

To me, that's one of the most impressive, obvious-in-hindsight-only advances in programming I've seen in the last couple of years.

--grendel drago

Power over Ethernet is not necessary, use the electricity in the TCP/IP connectivity.

See RFC3251, Electricity over TCP/IP. It's a very interesting read if you're not familiar with it.

You'd think there would be some restriction against 1-letter TLDs, but I can't find anything in the RFCs. I did find RFC 1591, which says "it is extremely unlikely that any other TLDs will be created", besides the country-code TLDs and the generic TLDs: EDU, COM, ORG, NET, GOV, MIL, and INT. I'd imagine that due to this, there's some code out there that assumes TLDs must be exactly 2 or 3 letters long.

Four-letter top-level domains (INFO and NAME, along with BIZ) have been around since 2001. Other new gTLDs have been added since then: MUSEUM, COOP, AERO, PRO, with JOBS possibly on the way. The full info can be found at the IANA. I've seen a few BIZ and INFO domains, and an AERO domain once. I don't think I've seen any of the others. On the whole, I'd say none of them ever really caught on. And yet they've got a few more in the works. Morons!

But I doubt that IIS coders are allowed to arrogantly pass the responsibility for its GUI functions off to the GDI or Forms people (which would be totally inappropriate).

Well, Sixteen Candles came out in 1984. According to this, PG-13 was invented that year, because people were upset with the rating Gremlins got (PG). So it's entirely possible that when Sixteen Candles was rated, PG-13 didn't exist, so the choices were R or PG. According to IMDB, it initially received an R, and then received PG on appeal, so that seems plausible.

I wish you would get an account, I don't generally reply to ACs but this was polite so...

"Unix Frame of Mind".. You mind explaining exactly what you mean by that?

There are lots of references art of unix programming has a good summary of some of the major ones.

Basically building systems with the assumption they will be incorporated into other systems in unexpected ways. This forces a flexible frame of mind which is very unlike what the GP was complaining about.

Just because it's open source doesn't automatically mean it's going to revolutionize the way they do their job.. especially if the software isn't tailored to do specifically that.. Most OSS software they would be using (Open Office etc) merely duplicate functionality of Windows equivalent while offering a few not really notable features.

Obviously open office in and of itself does nothing to change people's way of thinking. The question is whether openoffice opens the door to the Unix way of thinking or not.

RFC 792 dates back sep 1981.

wikipedia

FTP Software, a little company in N. Andover, MA, is correct. One of the founders was John Romkey who wrote the RFC for SLIP. They later got bought by Chameleon makers NetManage. The guts of their products in and around the TCP/IP stack were well-engineered, for an era when TSRs were standard and memory below 640K being precious.

To an operating system with TCP/IP, DECNET, IPX and SNA support -

OS/2

In the early 90's, if you wanted, you could get OS/2 to load a whole pile of transport protocols - which was pretty much necessary for the alphabet soup that ran client-server apps back then. In fact, Doom ran on IPX/SPX before it ran in TCP/IP.

By "higher auto safety", I am referring to "a significant reduction in road accidents/deaths", that you say is worth "[trading] part of [your] freedom/privacy". It turns out that our entire disagreement is irrelevant. Less freedom does not correlate with higher traffic safety (look for "data are all 1993"). So we don't have hard numbers on which to begin to debate whether "less freedom" of your country, possibly Belgium or France, would become more like Syria or more like Switzerland. I'd say that Syria (or worse) is the most likely model for reduced freedoms, as there are many Syrias, and only one Switzerland.

FWIW, I'm not sure why you keep complaining about "taunts" and "abuse". When I said I'd be the only one who knows about your willingness to trade liberty for security, I was commenting merely on the simple fact that your silence would allow ambiguity that I would of course resolve solely according to my own predisposition, without your help in resolution. If that is a "goad", then so be it. If you want to defend your assertions, you have to defend them. If you don't, you have to assume that those who disagree with you will consider them to be defeated in your silent retreat. As for what is necessary to get you to reply, your previously final words were "adieu, Doctor", which even Americans know means "goodbye".