Slashdot Mirror

Internet Engeneering Task Force, not explorer.

RFC: 791 Internet Protocol DARPA Internet Program Protocol Specification

Just fucking great. Instead of actually fixing the problem, they just told RFC 2396 (which is based on the ten year-old RFC 1738 and officially endorsed by the HTTP standard) to fuck itself and called it a day. And in the meantime, they recommend that users not click any links at all.

Just amazing that this is what we have to deal with.

Just fucking great. Instead of actually fixing the problem, they just told RFC 2396 (which is based on the ten year-old RFC 1738 and officially endorsed by the HTTP standard) to fuck itself and called it a day. And in the meantime, they recommend that users not click any links at all.

Just amazing that this is what we have to deal with.

3.3. HTTP

The HTTP URL scheme is used to designate Internet resources
accessible using HTTP (HyperText Transfer Protocol).

The HTTP protocol is specified elsewhere. This specification only
describes the syntax of HTTP URLs.

An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>,

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed. <path> is an HTTP selector, and <searchpart> is a query
string. The <path> is optional, as is the <searchpart> and its
preceding "?". If neither <path> nor <searchpart> is present, the "/"
may also be omitted.

Within the <path> and <searchpart> components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.

The Verisign Chief Scientist just proposed a solution on the ASRG list.

"Basically Microsoft should add a copyright notice to their turing test image and offer a free X-Box for the first person to report each site using a man in the middle attack to defeat it."

Later on

"Set up a bounty system for reporting such attacks, a free X-Box is probably more attractive than free porn. Or you could give a free X-Box and a subscription to your choice of Penthouse, Comopolitan or a non-porn title."

Cosmopolitan? A porn title? Err yes I guess it is.

Kinda sneaky, using one social network hack to defeat another.

Other RFC's list this syntax as "NOT RECOMMENDED" as it exposes the account information in plaintext, a sentiment I agree with. On the other hand, I realize that sometimes it needs to be used or security isn't that much of an issue and it is part of the standard.

URLs don't come in the form "name.subdomain.domain". According to the syntax for URLs in RFC2396, a URI (or URL) starts with the scheme (like http). So the patent should be about assigning URLs in the form "http://name.subdomain.domain/". The patent should be summarily thrown out for being incorrect.

This is ancient news, it has been mentioned by me on the ASRG list in November and on my blog. The original new article was published by the Post Gazette, and found by Matt McCay in his blog. Liudvikas Bukys mentioned it in his blog also. You might also want to take a look at the W3C draft on why these visual tests do not work for disabled people. And to end this off, the basic premise of C/R is that the return address is valid. Even if spammers break these visual tests, in order to do that, they must have a valid return address - ergo, making them traceable.

data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///y wA AAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCY sapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5 YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendz WTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeG l9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOz rcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97V riy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7

data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///y wA AAAAMAAwAAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCY sapyuvUUlvONmOZtfzgFzByTB10QgxOR0TqBQejhRNzOfkVJ+5 YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSpa/TPg7JpJHxyendz WTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJlZeG l9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOz rcd3iq9uisF81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97V riy/Xl4/f1cf5VWzXyym7PHhhx4dbgYKAAA7

So, has anyone heard of a word processor that has an XML file format that contains all its binary data? If so, post links under this thread :).

Not XML, but there is a URI format that lets you do it. See RFC2397. Yes, that is an RFC.

So, has anyone heard of a word processor that has an XML file format that contains all its binary data?

Does there need to be an implementation? XHTML has supported this since it was first published (Jan 2000, not including public drafts).

Specifically, you embed the binary data using the data: URL scheme, so, for example, you would write:

&lt;img src="data:image/jpeg;base64,ggifudghifudgdfig"&gt;

The data: URL scheme RFC was published in August 1998. However, to my knowledge, the only implementation was first created six months ago (the Opera web browser).

True, the avian carrier method is interesting, but I prefer this one:

RFC 1217

Now's as good a time to start drawing up the drafts as any.

http://www.ietf.org/rfc/rfc1149.txt

An interesting overview in the use of avian carriers for packet transport. Seems to follow with your point nicely though I'm concerned of packet loss due to falcon hacking.

-Matt

I couldn't get a php file uploaded either. I think it tries to execute the file. There's further information about this protocol here: http://www.ietf.org/rfc/rfc2518.txt. A COPY or MOVE to a php file doesn't appear to work either.

Forgot to paste in; of course, also RFC 1034 (section 3.3), published in 1987.

The patent itself is effectively fraud. Most of the document is occupied with long-winded noise designed to disguise the claim in a torrent of drivel by describing, in excruciatiating, irrelevent and confusingly-numbered detail, a webmail and fax system. The claim itself is only tangentially related to what is written.

Stealing the ideas in a decades-old technical standard? This is yet another embarrassing failure by the USPTO. - J

At least one specific recommendation by a governing body for using hostmaster.example.com. as a DNS label to represent "hostmaster@example.com" can be found here, published well before this patent was filed.

This can also be seen in RFC 1912 (section 2.2), published in 1996.

These muppets have patented something published in one of the very standards they should be familiar with.

- J

Egad! Can you belive this tripe? I feel dirty for even having felt the need to respond at all. That being said, here is some prior art... This is by no means an exhaustive list -- just an example of what good record keepers we the community can be:

RFC#2396: Uniform Resource Identifiers (URI): Generic Syntax, August 1998
RFC# 1738: Uniform Resource Locators (URL), December 1994
RFC# 1034: Domain Names - Concepts and Facilities, November 1987

Take that!

Egad! Can you belive this tripe? I feel dirty for even having felt the need to respond at all. That being said, here is some prior art... This is by no means an exhaustive list -- just an example of what good record keepers we the community can be:

RFC#2396: Uniform Resource Identifiers (URI): Generic Syntax, August 1998
RFC# 1738: Uniform Resource Locators (URL), December 1994
RFC# 1034: Domain Names - Concepts and Facilities, November 1987

Take that!

Egad! Can you belive this tripe? I feel dirty for even having felt the need to respond at all. That being said, here is some prior art... This is by no means an exhaustive list -- just an example of what good record keepers we the community can be:

RFC#2396: Uniform Resource Identifiers (URI): Generic Syntax, August 1998
RFC# 1738: Uniform Resource Locators (URL), December 1994
RFC# 1034: Domain Names - Concepts and Facilities, November 1987

Take that!

• must minimize unwanted messages -- probably
• must not affect delivery of wanted messages to the detriment of normal email -- probably
• must be easy to use -- for the end user, yes, but for organizations no (cryptography is a hard problem to solve right)
• must be easy to deploy, incrementally -- difficult to deploy because everyone has to upgrade their mta
• must not depend on universal deployment to be effective -- rats! Yahoo's system doesn't work very well unless everyone buys in
• must not reduce privacy -- cryptographically signing emails means less privacy
• must have minimal administration overhead -- Yahoo's solution requires maintaining a cryptographic framework, which is difficult
• must have minimal computation and bandwidth overhead -- how costly is it to sign each message? on busy servers it's very costly
• must consider the threat and be robust in the face of such threats -- not sure about this one...
• should consider how legal issues affect, support, or constrain the technical solution -- crypto is illegal in some countries

People can write XHTML code, but until web authors start to tell their web servers that they are sending XHTML then the UA will just get tag soup.

The moral is: Using a technology is worthless unless you implement it correctly. ... That and most people are still better off with HTML 4.01 Strict anyways.

This whole thing is moot with regards to Internet Explorer since they still haven't gotten around to supporting the line in XHTML documents yet, nor do they support the various xhtml mime-types.

Yeah you are right. I checked the RFC:
http://www.ietf.org/rfc/rfc2046.txt

So it looks lke Apache passing unknown MIME types as text/plain is incorrect behavior. I still think it would be good if there were MIME types for certain common file types that are causing the pain: .wmv, .rar, .dmg, and other common file types that have been causing pain, but I believe I was incorrect in my initial position, and Apache should be handling unknown types more correctly.

RFC 3489. Solution #1 from midcom, a
few others are in the pipe.

Many of the people responding to this thread are missing the big picture.
There will always be a screw-you-I'm-doing-this-the-OSS-way-with-crypto solution available. What does this solution cost? Well you might think it's free.

It isn't.

By adopting some OSS mechanism to communicate with whomever you choose, you impose a burden on the other party, namely, they have to install and have access to the same (or compatible) OSS VoIP software.

While this might be great for you and your hacker buddies, it won't help you call your parents, grandma, or your fiancee. It also won't help you call your doctor, lawyer, investment partner, stock broker or bank.


Wait, there's more going on here.

There are technical implication for the service providers. Most of the better designed VoIP protocols (like SIP, as an example) are all about establishing sessions. There is a location service somewhere that a user-agent (UA) (phone) can find, based on the number or URI that you call. This location service will either proxy your connection request to the other client, or it will redirect your user-agent to contact the other party directly. (Think HTTP 302 response code -- in fact -- SIP uses the same structure).

Once your UA has contacted the other party, some handshaking happens where you try to figure out what CODECs you will use to exchange audio, video, facsimile, IMs etc. Then end result is a collection of sessions directly between the user-agents that called one another.

Let me make that REALLY clear. Beyond the proxy / location service, the VSP (voice provider) is not in ANY way involved in the media flows. Why should it be? It doesn't care.

Enter CALEA requirements -- which are really poorly laid our I might add -- suddenly the VSP must carry the media and relay it to the other party and optionally duplicate each CODEC frame and send it to some black box (or red box as the case may be).

This has serious consequences on bandwidth consumption for VSPs.


But they can just do this when there is a tap! (You object)

And I counter with the fact that such an arrangement violates the CALEA requirements that a party subject to monitoring cannot know that they are under surveillance. End result? All media MUST flow through a choke point from which it could be duplicated.

This has catastrophic consequences on the bandwidth a VSP can expect to need to meet their service levels.

This may or may not be a Good Thing. I think it is NOT a Good Thing. One thing is certain, this issue is a very Material Thing for VSPs.

mDNS is a huge mess, mostly because Apple started deploying the thing without realizing that you'd have different hosts on the same network, some using mDNS and some using DNS (since not all hosts that are connected will see the same peers) and without bothering to figure out how to keep mDNS and DNS in sync.

the last time I looked the problem still wasn't solved. but the draft is in revision 27 after being taken on by an IETF working group, and still isn't done yet, which should tell you something about how ready it was for prime time when Apple shipped it.

the rest of Rendezvous (v4 linklocal addressing and DNS resource discovery) is also a huge mess, but that's another topic.

Actually, there already are provisions for this.
The SRV record, defined in rfc2782, is used to store a HOST:PORT pair

When will browsers (or anything else for that matter) start supporting this???

Here is a (possibly outdated) list of software that supports the SRV record.

The development team focused mainly on minor technical and legalistic issues like the naming of firebird, code clean up etc.
But they failed completely to incoperate the rising new mark-up technologies like XML-Signature or WebCGM.
If this development continues this year, Mozilla might lose it's technical lead to IE or Opera. And open source software might be again only the second winner.

SCTP (intro) would probably be good for this. It has most/all the functionality of TCP (retries, backoff, ...) as well as time-sensitive behavior and failover (it was designed for internet telephony signaling).

It's not widely deployed (but it does have Linux/BSD implementations), so you couldn't really use it unless you control the network and the attached computers.

SCTP (intro) would probably be good for this. It has most/all the functionality of TCP (retries, backoff, ...) as well as time-sensitive behavior and failover (it was designed for internet telephony signaling).

It's not widely deployed (but it does have Linux/BSD implementations), so you couldn't really use it unless you control the network and the attached computers.

May be you should try with IPv9 (RFC1606) or TCP Planet
(Performance of TCP Protocols in Deep Space Communication Networks TCP-Planet: A Reliable Transport Protocol for InterPlanetary Internet)

If you're going to network using pigeons, insist on open standards compliant pigeons. See RFC 1149 and RFC 2549

If you're going to network using pigeons, insist on open standards compliant pigeons. See RFC 1149 and RFC 2549

Granted, without the billing (because they feel that internet access should be free for their community), but many Dutch universities and research institutions together with SURFnet (the National Research and Education Network) have developed a roaming solution already. Based on IEEE 802.1x, EAP-TTLS and RADIUS it allows for seemless roaming between the participants.
This WiFi roaming has recently been extended and now institutions in Portugal and Croatia are joining as wel.

SPF was shot to ribbons on the IETF ASRG list...

SPF was shot to ribbons on the IETF ASRG list...

SPF was shot to ribbons on the IETF ASRG list...

Encapsulation may be done with saran wrappers. Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled.

How well will the Infinite Monkey Protocol Suite work over IP over Avian Carriers with QoS? Anyone try it? If you have any implementation tips, particularly for decreasing lag between ZOO and SIMIAN, please post them here.

Although lacking "quality of service information", the closely related RFC 1149 has been implemented by the Bergen LUG.

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

Would you rather choose a Yahoo product over an open standard that is under development? I'm speaking of AMTP, of course. (See AMTP author's site).

Yahoo's size doesn't give that much weight to their proposal. Yahoo's email is not used in business to business communication (do not count hot dog stands as businesses), so businesses can just aswell block everything that originates from *@yahoo.com if it is not directed to their consumer service department.

Also, reverse mx records provide much of the same benefits with minimal alterations needed to current email infrastructure. One DNS record added and small change in MTA software.

If Yahoo would really like to do a service to the internet community, they should rather consider looking AMTP and reverse mx records.

In fact, that applies to SMTP email in general. Consider all the mailing lists you read; they're "bulk email". That's one reason why spam filtering is harder in email than other protocols like IM; bulk one-to-many contact is a lot more common in the SMTP case. The IETF recognised this, and hence we have ESMTP.

Given this story, if I was Eric Allman or Wietse Venema, I'd be worried about people complaining that sendmail or postfix are spammer tools...

This is why Netmeeting and other H.323 solutions should be thrown on the trash heap.

This is why NAT should be thrown on the trash heap.

If your solution can't handle NAT, it is almost useless.

If NAT breaks solutions, then it is almost useless.

There are certain rules for providing internet access, defined 23 years ago in RFC 760 (etc). NAT breaks those rules. If you use NAT, you don't have Internet access. If you don't have Internet access, you shouldn't expect Internet applications to work.

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information

• VOVIDA
• RFC 3261 -- Session Initiation Protocol
• RFC 3263 -- Location of SIP Services
• The SIP Working Group Charter
• Additional SIP WG Info

• The SIPPING Working Group
• Additional SIPPING information