Slashdot Mirror

Regarding:

This document specifies HTTP extensions that bridge the current location-based Web with the Content-Addressable Web. -- HTTP Extensions for a Content-Addressable Web

The World Wide Web is "the universe of network-accessible information", i.e. anything with a URI, including URIs that are not tied to a particular hostname.

The Web already includes non-location-based URIs like mid: (for referring to message-ids), and urn:sha1: for referring to a specific set of bits by their checksum.

This proposal seems like a decent way of bridging HTTP-space with URN-space, but please remember that the Web is more than just HTTP. (see also: URIs, URLs, and URNs)

Anyway, it seems to me that sites that tend to suffer from slashdotting are:

1. those that use dynamically-generated pages for what is basically static content: this problem can be fixed by sites making sure their content is cacheable, and further deployment of HTTP caches. (I'm not convinced a p2p-style solution is the solution here.)

2. those with large bandwidth needs (kernel images, linux distribution .iso's, multimedia): as p2p software becomes more mature and widely deployed, everyone will have a urn:sha1: resolver on their desktop (pointing to their p2p software of choice), then whenever a new kernel is announced, the announcement can say:

   Linux kernel version 2.4.20 has been released. It is available from:
   
   Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2 .4.20.gz
   a.k.a. urn:sha1:OWXEOVAK2YJW3G6XSULXDWFCNWTX7B2K
   Full source: ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2 .4.20.tar.gz
   a.k.a. urn:sha1:PPWXYMA32YNDNO35UD3IQTCWBVBYK5DC

   and people can just fetch the files using urn:sha1 URIs instead of everyone hitting the same set of mirrors. (gtk-gnutella already supports searching on urn:sha1: URIs)

See also RFC 3425, "Obsoleting IQUERY".

Now we get to see how PostgreSQL handles those 98 % of wasted inquiries from DNS servers that don't know .elvis is not a TLD.

org. is tld (top level domain).

. (dot) is the root.

the story on the wasted 98% was about the . (dot) root servers, not about a tld server. you (and sadly, too many others) should read rfc 1035.

A recent survey of 1 million monkeys indicates that 99.99% of them say that computers are unnecessary

But the remaining 0.01% of monekys need DNS to communicate using the Infinite Monkey Protocol Suite

Before you go running in the streets naked yelling Eureka, consider the privacy implication of the said technology and other related issues. Google it. Thanks.

Internet access on Mars? Hmmm...

buzzbomb@mars:~$ ping yahoo.com
PING yahoo.com (64.58.79.230): 56 octets data
64 octets from 64.58.79.230: icmp_seq=0 ttl=242 time=757610.6 ms
64 octets from 64.58.79.230: icmp_seq=1 ttl=242 time=757638.2 ms
64 octets from 64.58.79.230: icmp_seq=2 ttl=242 time=757620.5 ms

--- yahoo.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 757610.6/757623.1/757638.2 ms


Well, it's faster than the actual implementation of RFC 1149.

Don't know if we already have this or not, but don't we first need a common voice protocol that is agreed upon and used by all? Kind of like something as ubiqious as TCP?

The IETF has quite a few RFC's on the subject:

For transport: RTP
For call setup: SIP
For resource reservation: RSVP
SIP is actually being used in UMTS networks for call setup.

Don't know if we already have this or not, but don't we first need a common voice protocol that is agreed upon and used by all? Kind of like something as ubiqious as TCP?

The IETF has quite a few RFC's on the subject:

For transport: RTP
For call setup: SIP
For resource reservation: RSVP
SIP is actually being used in UMTS networks for call setup.

Don't know if we already have this or not, but don't we first need a common voice protocol that is agreed upon and used by all? Kind of like something as ubiqious as TCP?

The IETF has quite a few RFC's on the subject:

For transport: RTP
For call setup: SIP
For resource reservation: RSVP
SIP is actually being used in UMTS networks for call setup.

Reminds me of DNS LOC

Also, check out RFC 1876 - A Means for Expressing Location Information in the Domain Name System

You said: "Well, I suppose when Bush wins in 2004 and we all move to Australia, we'll have to run our file-sharing apps via carrier pidgeon."

Fortunately they'll be prepared. There is a protocol: RFC 1149 and a sucessful test by a LUG in Norway.

Thanks to some vagueness in the standards defining IP datagram transmission on Ethernet networks, it's not entirely clear exactly how the padding should be done.

When necessary, the data field should be padded (with octets of zero) to meet the IEEE 802 minimum frame size requirements.

So, while it isn't clear where the values of zero should come from, it looks clear to me that they should be zeroe values, and not values pulled from some previously used buffer or packet.

Your punishment is very simple: You are to write a functioning recursive DNS server. This server has to resolve domains well enough to give an end-user a satisfactory web surfing experience.

After doing this, you will then post an essay to Slashdot concerning your opinion of the DNS spec and well-designed it is.

You will, I assure you, have an experience akin to seeing the movie Highlander II. You hopes for DNS being a decent protocol will become, rather quickly, a big dissapointment. But don't take my word for it. Don't take Dan Bernstein's word for it. Do it yourself and become an exclusive member of the club of People Crazy Enough to Actually Write a Recursive DNS Server. After all, we all know that people who log in as anonymous cowards and flame free software developers are the best programmers that the world has; I am sure you can do this in a week. Once you do this, you too will know why a number of DNS server projects die around the point when the potential DNS implementor in question looks at how recursive resolution is actually done.

If you continue to flame free software developers after doing this, your punishment will be escalated to having to write a recursive DNS server which recursively resolves names according to RFC 1034, while not having any security problems.

If you persist in your flaming ways after doing that, your next punsihment will be to write a C++ compiler which implements everything in the C++ spec, and release said compiler under the GPL.

And, if you continue to insist on flaming free software devlopers after that...well, you won't be, by this point. You'll be too busily getting flamed by anonymous cowards on Slashdot to do any flaming yourself.

- Sam

Try it yourself -- use windump (tcpdump for Windows) to capture the packet trace.

Report back, share the news. I don't think there is a real "request" packet as mentioned in the blog article, but would sure like to see it. If there is such a packet, perhaps it's Transactional TCP (RFC1644).

Not a standard. RFC 1644 is classed experimental; it's not a standards-track protocol. See The Internet Standards Process (RFC 2026). The claim in the story leader that Microsoft were somehow ignoring RFCs looks, uh, foolish though, which is the point you were making.

This sounds about as funny as RFC 1149 IP over Pigeon

Icap seems dead, and mcal languishing..

This is awesome! Now, does anyone have a speech-to-text program that accepts ogg streams as input?

If you prefer using open standards route, then you might want to look at transfering the Linux src via the Carrier Pigeon Internet Protocol (CPIP) instead.

(Of ocurse you'd have to do something like ftp over cpip).

ANd I'm not talking about something like Jabber.

Despite your protest, that is the answer. The IETF has formed the XMPP working group, where XMPP stands for "Extensible Messaging and Presence Protocol", which should become the interoperability standard for instant messaging services; it's certainly the closest thing we've got. And XMPP is basically Jabber with a spit-polish.

So, yes, you are talking about XMPP ne* Jabber.

(*: should have an accent on it)

There is: ESMTP. Provides a framework for extending SMTP, including allowing for username/password authentication. Wrap it with SSL/TLS and you're good to go. Most of the popular MTA's (sendmail, postfix, qmail) either have built-in support or patches available, and many popular MUA's (outlook/oe, mozilla, evolution) support it as well.

People who fear that a switch from US-ASCII to UTF-8 will break their existing programs should really read the Bell Labs document linked above, section 2.3 of the Unicode spec, or RFC 2044. UTF-8 was designed very carefully to make life extremely easy for people making that exact migration. There are amazingly few circumstances where it even matters that it is variable width. Those people who are suggesting UCS-2, UCS-4, etc. as alternatives in order to solve the nonexistant problem of UTF-8's variable width nature should really take a closer look at it.

Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l

VRRP Internet draft :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt

VRRP for IPv6 :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt

VRRP RFC :: http://www.ietf.org/rfc/rfc2338.txt

Email the chair of VRRP :: mailto:Mukesh.Gupta@nokia.com

Mailing list archive :: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l

VRRP Internet draft :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt

VRRP for IPv6 :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt

VRRP RFC :: http://www.ietf.org/rfc/rfc2338.txt

Email the chair of VRRP :: mailto:Mukesh.Gupta@nokia.com

Mailing list archive :: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l

VRRP Internet draft :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt

VRRP for IPv6 :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt

VRRP RFC :: http://www.ietf.org/rfc/rfc2338.txt

Email the chair of VRRP :: mailto:Mukesh.Gupta@nokia.com

Mailing list archive :: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l

VRRP Internet draft :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt

VRRP for IPv6 :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt

VRRP RFC :: http://www.ietf.org/rfc/rfc2338.txt

Email the chair of VRRP :: mailto:Mukesh.Gupta@nokia.com

Mailing list archive :: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

Home Web page of the VRRP working group :: http://www.ietf.org/html.charters/vrrp-charter.htm l

VRRP Internet draft :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-spec-v2-06.txt

VRRP for IPv6 :: http://www.ietf.org/internet-drafts/draft-ietf-vrr p-ipv6-spec-03.txt

VRRP RFC :: http://www.ietf.org/rfc/rfc2338.txt

Email the chair of VRRP :: mailto:Mukesh.Gupta@nokia.com

Mailing list archive :: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

I am not aware of any open source project that has ships VRRP. The IETF has received more information from Cisco about their Intellectual Possession in regards to VRRP.

Yet another reason we should all use Data: URL's

Valid points, all. Keep in mind, though, that the syslog protocol runs on all sorts of systems, not just servers. It is still true that a simple, UDP-based protocol is easier on embedded hardware than a complex, TCP-based one.

Also, the function of syslog is not only to log routine diagnostic messages but also "distress calls", where the ailing system may only be able to squirt a few bytes onto the network before dying. Formatting, handshakes and authentication are all potential obstacles.

I think that a reliable syslogd is very important, for the reasons you mentioned and more. Sometimes the data recorded by standard syslogd is useless, making its design a liability. But its simple design helped ensure its acceptance. See RFC 3164 for historical notes and a review of the syslog protocol--section 1 is of great relevance.

Here is a slightly bulked up version of my submission for this story:

Ok first, the official name used to be IEEE-1394, but not surprisingly, eventually they decided to just go with FireWire (which was previously an Apple-only name for the technology). Current version is 1394a which tops out at 400 Mbps, next is 1394b which starts at 800 Mbps.

Apple has been a strong proponent and developer of the technology. Sony also (they like to call it i.Link) Mostly it is used to connect to DV cams, but you can also use it for other peripherals that need high speed. I use it for my external hard drive and an external CD burner. But of course, you could also in theory use it for networking. Hence, IP-over-FireWire (as compared to say, the current IP-over-Ethernet). The standard specifying this is RFC 2734. (To be very technical, this only specifies the IPv4 implementation.)

Microsoft supports 1394 and in particular had an IP1394 stack for a while, in ME and now in XP. The Linux 1394 project has been working on it, but it had a lot of trouble getting off the ground. And now (finally) IP1394 is available from Apple.

It will be interesting to see if the Apple implementation interoperates with the Microsoft one.

My Master's project is on this topic. My school page is sadly out-of-date, I need to update it ASAP.

That's why I block those accounts

I know its a throwback to the days of yore, but those accounts are required to accept mail per RFC 2142 (scroll down to #5). In this world of total non-compliance, lets offer a moment of silence in memory of how the Internet was *intended* to run. :)

What's needed is some way to reserve bandwidth in advance, some kind of ICMP packet that says 'I want to be able to send packets quickly to the following address during the next three hours'. The router will reply with 'okay' or 'no, I can't guarantee that'.

Ed Avis, you've just invented RSVP. What are you going to do next?

"I'm going to Disneyland!"

This kind of crap is exactly what it would take to make me cancel my account with my ISP and do everything by paper again.

Here's an RFC to help you with the transition to paper-based Internet access.

...and here's a group of people who've implemented it, and here's the article /. ran on it.

This kind of crap is exactly what it would take to make me cancel my account with my ISP and do everything by paper again.

Here's an RFC to help you with the transition to paper-based Internet access.

IPsec here.
And here.
And you can even check out the sexy girl in the ad for SSH here.

Actually, I was just kidding; I understand what the address represents. But your answer isn't quite right, anyway. I suggest you check out part 3 of RFC 1918 if you're interested.

RFC = Request for Comments , not necessarily always established standards, but mostly proposed standards.

You could include references in your inmensely constructive comments. Of course for a technology to be useful to anyone, RFCs are required reading. Where is the RFC you mention (PGP in XML) ?

No, what you bought was low-priced commodity Internet access.

Read through the IETF RFCs for a few months, and you can extract the definition of Internet Access. It means that if a computer has Internet Access, it can open any 16 bit port and send TCP or UDP to any other host which also has Internet Access. (If some packets get delayed or randomly dropped, it still counts. But block them entirely, and they can't reach The Internet anymore)

Ask Metcalf, Cerf, or Berners-Lee and they'll tell you the same.

To advertise "Internet Access" and then only provide a subset of it is misleading, and if regulators were more tech-savvy they'd fine many ISPs for false advertising. If carriers think they can pick and choose what ports and protocols to allow, then they should rename the service to "HTTP Client / Email / IM access" and at least be forthright about it.

One thing I hate is having to "log in with the plaintext password I store and mail you every month without fail to some random mailing list name to do anything because this MLM is too braindead to understand listname-requests, or even listname-(command)".

Whatever you use, make sure it has a clean email interface, and configure it to include rfc2369/rfc2919 List-(Subscribe|Unsubscribe|Post|Help|Owner|Id) headers so I can filter and automate control of it.

Ecartis is a great example of a MLM with support for both email and web-based manglement. Email is the standard double-opt-(in|out) stuff, with various other methods of authentication to make sending batched/automated commands easy for admins. Web emails you a "cookie" (effectively a temporary password), and lets you set up a (secure) password once logged in; if you forget your password, you just don't include it on login and get another cookie.

No monthly spam with one of your passwords going out for all to see to some random location in your filters (mine end up in lists/(test|news|announcements)), and an extensive but by no means required web interface, without the need for a monthly insecure irritating to filter spam.

One thing I hate is having to "log in with the plaintext password I store and mail you every month without fail to some random mailing list name to do anything because this MLM is too braindead to understand listname-requests, or even listname-(command)".

Whatever you use, make sure it has a clean email interface, and configure it to include rfc2369/rfc2919 List-(Subscribe|Unsubscribe|Post|Help|Owner|Id) headers so I can filter and automate control of it.

Ecartis is a great example of a MLM with support for both email and web-based manglement. Email is the standard double-opt-(in|out) stuff, with various other methods of authentication to make sending batched/automated commands easy for admins. Web emails you a "cookie" (effectively a temporary password), and lets you set up a (secure) password once logged in; if you forget your password, you just don't include it on login and get another cookie.

No monthly spam with one of your passwords going out for all to see to some random location in your filters (mine end up in lists/(test|news|announcements)), and an extensive but by no means required web interface, without the need for a monthly insecure irritating to filter spam.

Offtopic I know but for the ultimate in bad latancy try this link. An implementation of RFC-1149

IT DOESN'T MATTER HOW FANCY YOUR PROTOCOL IS OR HOW GOOD YOUR CRYPTOGRAPHY IS, IF THEY CAN GET YOUR IP YOUR SCREWED.

*ears ringing*

I have NEVER seen a p2p system address this issue.

No, it would probably require changing the IP layer to something more exotic. And don't say CPIP-based solutions doesn't work! :-)

If they want to close all of the ports they are going to have to close ALL of the ports.

If they close all IP ports I'll just adapt RFC 1149 to function over cargo ships though sea ports. If they close the sea ports I'll just adapt it to use passenger jets through the airports.

P.S.
the ping times involved are a bit of an annoyance on live voice data though.

-

An article on News.com mentions that "the new working group could have some competition from IBM and Microsoft, which have promoted a separate standard known as SIMPLE". This also has a IETF working group - here's the charter

Meanwhile a group of users in finance industry are pushing for exactly this sort of integrated solution. Called FIMA they "say it is non-partisan, and is open to any company that wishes to promote Internet Engineering Task Force (IETF) IM standards and protocols within the financial services community. By endorsing IETF instant-messaging standards, FIMA wants to promote "interoperability and beneficial competition among instant-messaging vendors."

There is an air of enevitability about the integration of protocols - but it may not be based on Jabber.... but SIMPLE doesn't sound all that hot...

Instant Messaging and Presence Protocol (IMPP)
SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
Session Initiation Protocol (SIP)
Common Presence and Instant Messaging (CPIM) (Still a draft)

In addition to these guys, Wireless Village is an IM standard created by Ericsson, Motorola, and Nokia. It's getting very strong traction among wireless carriers who want to deploy IM on phones and other mobile devices. Of these different offerings, SIP isn't strictly an IM thing, but there are people trying to use it to set up IM sessions. Microsoft uses SIP in their Messenger offering (which is how they claim they are "standards-based").

CPIM is probably dead.

IMPP has some traction in the 3GPP wireless groups, but not really anywhere else (read "probably dead").

SIMPLE has tons of backers including IBM (Lotus) and is probably going to emerge as one of the dominant standards.

Jabber is just trying to stay afloat in all this standards chaos. This was a very good move for them since they actually have millions of deployed users. Jabber is the only IETF-related working group that can claim real-world deployment like this. None of the other standards have any subtantial deployed user base (if any users at all).

Probably what will happen is that as IM servers emerge, they will support a handful of these protocols, just like email servers currently support IMAP, POP, etc.

Notice that AOL, ICQ, MSN and Yahoo! are not pushing their protocols as standards anymore. They are plying the Mexican stand-off thing and probably will have to scramble to jump on one of these standards as things shake out.

Instant Messaging and Presence Protocol (IMPP)
SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
Session Initiation Protocol (SIP)
Common Presence and Instant Messaging (CPIM) (Still a draft)

In addition to these guys, Wireless Village is an IM standard created by Ericsson, Motorola, and Nokia. It's getting very strong traction among wireless carriers who want to deploy IM on phones and other mobile devices. Of these different offerings, SIP isn't strictly an IM thing, but there are people trying to use it to set up IM sessions. Microsoft uses SIP in their Messenger offering (which is how they claim they are "standards-based").

CPIM is probably dead.

IMPP has some traction in the 3GPP wireless groups, but not really anywhere else (read "probably dead").

SIMPLE has tons of backers including IBM (Lotus) and is probably going to emerge as one of the dominant standards.

Jabber is just trying to stay afloat in all this standards chaos. This was a very good move for them since they actually have millions of deployed users. Jabber is the only IETF-related working group that can claim real-world deployment like this. None of the other standards have any subtantial deployed user base (if any users at all).

Probably what will happen is that as IM servers emerge, they will support a handful of these protocols, just like email servers currently support IMAP, POP, etc.

Notice that AOL, ICQ, MSN and Yahoo! are not pushing their protocols as standards anymore. They are plying the Mexican stand-off thing and probably will have to scramble to jump on one of these standards as things shake out.

Instant Messaging and Presence Protocol (IMPP)
SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
Session Initiation Protocol (SIP)
Common Presence and Instant Messaging (CPIM) (Still a draft)

In addition to these guys, Wireless Village is an IM standard created by Ericsson, Motorola, and Nokia. It's getting very strong traction among wireless carriers who want to deploy IM on phones and other mobile devices. Of these different offerings, SIP isn't strictly an IM thing, but there are people trying to use it to set up IM sessions. Microsoft uses SIP in their Messenger offering (which is how they claim they are "standards-based").

CPIM is probably dead.

IMPP has some traction in the 3GPP wireless groups, but not really anywhere else (read "probably dead").

SIMPLE has tons of backers including IBM (Lotus) and is probably going to emerge as one of the dominant standards.

Jabber is just trying to stay afloat in all this standards chaos. This was a very good move for them since they actually have millions of deployed users. Jabber is the only IETF-related working group that can claim real-world deployment like this. None of the other standards have any subtantial deployed user base (if any users at all).

Probably what will happen is that as IM servers emerge, they will support a handful of these protocols, just like email servers currently support IMAP, POP, etc.

Notice that AOL, ICQ, MSN and Yahoo! are not pushing their protocols as standards anymore. They are plying the Mexican stand-off thing and probably will have to scramble to jump on one of these standards as things shake out.

Instant Messaging and Presence Protocol (IMPP)
SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
Session Initiation Protocol (SIP)
Common Presence and Instant Messaging (CPIM) (Still a draft)

In addition to these guys, Wireless Village is an IM standard created by Ericsson, Motorola, and Nokia. It's getting very strong traction among wireless carriers who want to deploy IM on phones and other mobile devices. Of these different offerings, SIP isn't strictly an IM thing, but there are people trying to use it to set up IM sessions. Microsoft uses SIP in their Messenger offering (which is how they claim they are "standards-based").

CPIM is probably dead.

IMPP has some traction in the 3GPP wireless groups, but not really anywhere else (read "probably dead").

SIMPLE has tons of backers including IBM (Lotus) and is probably going to emerge as one of the dominant standards.

Jabber is just trying to stay afloat in all this standards chaos. This was a very good move for them since they actually have millions of deployed users. Jabber is the only IETF-related working group that can claim real-world deployment like this. None of the other standards have any subtantial deployed user base (if any users at all).

Probably what will happen is that as IM servers emerge, they will support a handful of these protocols, just like email servers currently support IMAP, POP, etc.

Notice that AOL, ICQ, MSN and Yahoo! are not pushing their protocols as standards anymore. They are plying the Mexican stand-off thing and probably will have to scramble to jump on one of these standards as things shake out.

AgentX is actually an IETF sub-agent protocol for use with SNMP. Though no longer officially on the List of currently active working groups, it's fairly widely used.