Slashdot Mirror

No, the plan is to hand out a /48 even to dialup customers.

Various possible solutions:

Clients can request individual packets are resent to them alone (works well if packet loss is very low).

Server continuously re-broadcasts data for a few days, so if you miss it the first time, you can get it the second/third/fourth/whateverth time (generally referred to as carousel).

Forward Error Codes: http://rfc3453.x42.com/

I wonder how this will effect RFC 4109 in that it depreciates MD5 in favor of SHA1. Does this mean that SHA1, at 2^63 is less secure than MD5 at a brute-force 2^64? I'm not a crypto expert or anything, just asking the question; will this effect the proposed standard for the HASH algorithm used in IPsec?

Internet over telephone lines (dialup/DSL).
Telephony via the internet (VOIP).

Internet via Cable.
TV via internet.

Internet via wireless.
Internet radio.

IP via Avian protocol (see the RFC).
Birds on the internet (will not provide any links).

Internet via power lines.
Power to the People, via the web (Power to the People).

It may be a joke, but I for one welcome our new nonet-using PDP10 overlords. (It would be better with nonets of balanced trits, but hey...)

Also see this summary of friday 13th distribution throughout the years: http://x42.com/datelab/

There's a published standard which TMDA complies with to announce that it's challenges are machine generated. You can filter on it or not, but it's the way that all machine generated emails are supposed to be advertised.

To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stuff conform to RFC 2778 and RFC 2779, which means that they are very much compatible, given an appropriate gateway. In fact, when XMPP is finished with their work (the document that was just approved is only their first document, and doesn't even describe how to do instant messaging), you'll be able to send signed and encrypted messages back and forth between the systems.

And while people have already written gateways between the protocols, you are more than welcome to add another one to the growing pile -- but I might suggest that you have a lot of learning to do first.

To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stuff conform to RFC 2778 and RFC 2779, which means that they are very much compatible, given an appropriate gateway. In fact, when XMPP is finished with their work (the document that was just approved is only their first document, and doesn't even describe how to do instant messaging), you'll be able to send signed and encrypted messages back and forth between the systems.

And while people have already written gateways between the protocols, you are more than welcome to add another one to the growing pile -- but I might suggest that you have a lot of learning to do first.

To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stuff conform to RFC 2778 and RFC 2779, which means that they are very much compatible, given an appropriate gateway. In fact, when XMPP is finished with their work (the document that was just approved is only their first document, and doesn't even describe how to do instant messaging), you'll be able to send signed and encrypted messages back and forth between the systems.

And while people have already written gateways between the protocols, you are more than welcome to add another one to the growing pile -- but I might suggest that you have a lot of learning to do first.

To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stuff conform to RFC 2778 and RFC 2779, which means that they are very much compatible, given an appropriate gateway. In fact, when XMPP is finished with their work (the document that was just approved is only their first document, and doesn't even describe how to do instant messaging), you'll be able to send signed and encrypted messages back and forth between the systems.

And while people have already written gateways between the protocols, you are more than welcome to add another one to the growing pile -- but I might suggest that you have a lot of learning to do first.

To ensure compatibility, both the SIP IM stuff (done in a working group called SIMPLE) and the XMPP IM stuff conform to RFC 2778 and RFC 2779, which means that they are very much compatible, given an appropriate gateway. In fact, when XMPP is finished with their work (the document that was just approved is only their first document, and doesn't even describe how to do instant messaging), you'll be able to send signed and encrypted messages back and forth between the systems.

And while people have already written gateways between the protocols, you are more than welcome to add another one to the growing pile -- but I might suggest that you have a lot of learning to do first.

As many have mentioned .zip is an open standard.
In fact, it's rfc 1951". It's the use of encryption that's an issue. Open standards like AES or PGP exist for that as well. What should happen is: Define an rfc for formats using encryption with compression. Then there is an agreed upon implementation, rather than multiple companies trying to define an implemenation. Isn't that what the IETF is for?

The big question is why it doesn't support the VoIP standard rendevouz mechanism, namely SIP, defined by RFC3261 and supported by many ip-phones software and hardware out there.
H323 is dead. Should be, anyway.

Half-close? As in half-correct? I thought this is a three-way handshake, which is a necessity as the underlying protocol is considered unreliable.
RFC 761 it is explicitly stated that both connecting and disconnecting involves a three-way handshake with SYN/ACKs and in the case of disconnecting FIN/ACKs.

Of course, the second FIN may be lost (or not send at all, as in MSIEs case), so additionally there is a time-out, which will make the connection close anyway. But this is somehow undermining the sense of the ACKs.

In RFC 793 (supersedes RFC 761) 3.1, I read nothing about a "half-close".

That's great it displays text backwards and all, but mirrors don't reverse the order text. Make yourself a nice big "R" and hold it in front of a mirror. See the difference?

If you use a mirror to read this google mirror you are going to see the letters in the right order, but they are all going to be backwards!

It is possible (and easy) to reverse the entire page with IE: http://x42.com/test/flip.html

Mirror picture here

I've mirrored the comment page and the patch
here for your pleasure.

I remember doing this on a embedded FORTH-system in the 80-ies. The only way to communicate with the board when the RS232 was gone was a little piezo-beeper.

The RFCs are available on x42.com here and here. As linked to by the RFC slashbox...

The RFCs are available on x42.com here and here. As linked to by the RFC slashbox...

The RFCs are available on x42.com here and here. As linked to by the RFC slashbox...

for an example, see this page on decimal URLs

http://rfc3098.x42.com/

--
Darren Stuart Embry

English words are left hands. Check out the number of complete words you can type one-handed using normal typing (home keys+up and down rows), courtesy of x42.com. For the lazy, there's 1447 complete words you can type left-hand-only, compared to 187 right-hand-only (not moving from that side of the keyboard, mind you)

So, left hand on the keyboard, right on the mouse (and using the right to CRLF using the numberpad Enter key) is the ideal setup for lots of situations.

I'm sure everyone has their own favorite mirror, but I like x42.com's RFCs. You can get these two at rfc2821.x42.com and rfc2822.x42.com.

I'm sure everyone has their own favorite mirror, but I like x42.com's RFCs. You can get these two at rfc2821.x42.com and rfc2822.x42.com.

I'm sure everyone has their own favorite mirror, but I like x42.com's RFCs. You can get these two at rfc2821.x42.com and rfc2822.x42.com.

Worth reading now is the new RFC on SPAM:

How to Advertise Responsibly Using E-Mail and Newsgroups

or - how NOT to

$$$$$ MAKE ENEMIES FAST! $$$$$

http://rfc3098.x42.com/

/magnus

Rrrright!
But still, i guess none of us would have spent so much time reading and posting on this subject if there were no _real_ problems with the web browsers. And, by the way, check out this page, try to see it from both Netscape and MSIE and let's talk about 'malformed content' after, ok?

b0nechina
--
b0nechina

Good point - I believe that this is what RFC2827 partially attempts to address.

----

also, you need not bust out a calculator to do this, as it can be done from x42.com.

Or if you're too lazy to do it yourself you can let the folks over at x42.com do it for you :-)

/magnus

• http://rfc.x42.com/
• http://clock.x42.com/
• http://x42.com/urlcalc/

• http://rfc.x42.com/
• http://clock.x42.com/
• http://x42.com/urlcalc/

• http://rfc.x42.com/
• http://clock.x42.com/
• http://x42.com/urlcalc/

• http://rfc.x42.com/
• http://clock.x42.com/
• http://x42.com/urlcalc/

http://x42.com/urlcalc/

This is really a very clever hack. It's only obvious once you hear it. I'm against "intellectual property" in general, but I still recognize that this is a novel idea. I honestly can't see the patent being attacked on the basis that it is "obvious". (Though I can see it being attacked on other grounds: the very idea of patents is absurd, no research went into "inventing" this, someone must have done it already, and it obviously would not do all that much good for society if this were restricted). But it's still not "obvious".

According to the copyright notice on the page, this has been up since 1998-06-23, and has won the "Useless site of the year award" for 1998.

Perhaps it wasn't so useless after all.

http://this is a url with spaces.x42.com/
sucker.

http://åäö.x42.com/ and http://this is an url with spaces.x42.com/ And you'll see strange URL:s before any strange DNS RFC change appears.

http://åäö.x42.com/ and http://this is an url with spaces.x42.com/ And you'll see strange URL:s before any strange DNS RFC change appears.