Slashdot Mirror

I thought this was solved by Punycode, RFC 3492 http://www.ietf.org/rfc/rfc3492.txt, over three years ago. It is "Standards Track"; all major browsers support it; and it does not break the entire Internet.

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

There's also ACP (Avian Carrier Protocol), described in RFC 1149 back in 1990.

you'd think they could devote some of their time to have someone simply set all the clocks on all the hardware for the time of that night's transition

or point the software at an NTP server and set that to the time it transitions.

That just gives loads of strange irrelevant patents on electronic ink and the link. What actual patents are infringing?

The point here is that Microsoft hasn't actually specified any patents. Maybe they exist, maybe they don't. Maybe they're valid, or maybe they're overbroad rubbish which are worth challenging. Compare and contrast Adobe's PDF license which is very clear about precisely which patents are being infringed.

Microsoft is FUDding like mad, and we're being taken in by it.

Rich.

I'm reasonably knowledgeable about working with CPanel (all I have to work with on a a reseller account. But it feels as though I need to RTFM for SMTP in order to decipher how to use SPF when most my domain's email originates via my home DSL (covad.net) and must be sent via smtpauth.earthlink.net as they filter port 25.

What would be a much better solution all the way around IMHO is if servers were set up only to generate bounce messages to local users, and if people would STOP using challenge-response systems to try and combat spam--they only create more spam for everyone else!

In that case, the RFC has got your back.

Try reading the recc or RFC 3236 sometime. There's no problem serving XHTML to clients advertising the appropriate MIME string via accept. It's treated as XML otherwise it's served as text/html and treated as HTML.

That's the way XHTML was designed, the only problem here exists within Hixies head.

In 2003 approx 64% of households in Canada were connected.

But there seems a problem to catch the content of the self-supplied links properly.

First qoute: An estimated 7.9 million (64%) of the 12.3 million Canadian households had at least one member who used the Internet regularly in 2003, either from home, work, school, a public library or another location.

A little later, 2nd quote: Internet use was highest at home. About 6.7 million households had at least one member who regularly used the Internet from home, ... These households accounted for nearly 55% of the total ...

Or maybe I missed RFC 1149 in its full scope.

CC.

"All Cisco has to do is quit beating competitors over the head with patents and other anti-competitive practices and compete off of merrit and service instead."

Perhaps you would care to elaborate on your basis for this accusation...

From my experience, Cisco has one of the most generous patent-licensing policies in the industry... As an example, look at VRRP... covered by a Cisco patent, but Cisco has agreed to let the world implement the technology in a reasonable and non-discriminatory fashion [ ref http://www.ietf.org/ietf/IPR/VRRP-CISCO ]... far from the anti-competitive slant described.

Cisco-originated patent-infringement lawsuits are normally a last-resort after they have begged the offender to stop and the damage is quite serious... for instance, witness the Huawei debacle where they literally found Cisco copyright strings throughout the Huawei binaries... hard evidence that someone took significant portions of Cisco source-code and copied it line for line.

Apache added support for RFC 2817 to mod_ssl about a year ago, in Apache HTTPD 2.2. Admittedly, not many people are using 2.2 yet; a lot of servers are still running 1.3.

I could not find any indication that Mozilla/Firefox support RFC 2817. (I read one email archive that said it did, but bugzilla says it has not been implemented.)

I found the answer to my question regarding IE7 support: it will not support RFC 2817. It will however, support RFC 3546 (SNI) in the Vista version, which is apparently a better method of getting the same functionality. (The reply to the above Slashdot comment includes some info and links on SNI.) Mozilla does not yet support SNI. Apache does not support SNI out of the box; the mod_gnutls module does, but it's not included with Apache, and is not yet production quality. There is a patch for Apache mod_ssl.

Summary: It appears that SNI will be the way forward, but consensus and implementations still need to catch up. IE7/Vista is the second browser implementation after Opera. Apache and Mozilla do not yet support it, but are working on it. Here's a decent write-up about the situation.

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004], the then-current Sender ID specification draft-ietf-marid-protocol-03 did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records until the end of October, when they began generating only "v=spf1" records.

Read the appeal. It connects a lot of dots that many do not like to remember.

There are certainly problems with DomainKey and DKIM but I cannot glean from what you wrote that you and I agree on what those problems are. If you do NOT modify the body or one of the protected headers, DKIM will pass validation no problem (I say this as someone who has his mail validated this way every day).

I will speak to DKIM since that is what the IETF is standardizing on, and that is the code you can get for free on SourceForge. DKIM's biggest advantage is that it does not care about how the mail gets to your mailbox, that there might be intervening MX forwarders or other mechanisms, that convolute the path, and that these may or may not participate in whatever path-based games SPF and Sender-ID presume. DKIM's biggest disadvantage is not for everyday mail, but primarily relating to mailing lists, where validation of the content becomes a problem, when it is altered. A DKIM header contains a header signature and a body hash. The body hash becomes invalid when you add stuff like mailing list info, or if you normalize the output in any way, which some systems do.

The answer to all of this is for those systems to take responsibility for the message and apply appropriate policies before forwarding. This means that a mailing list should, yes, check whatever reputation service and then make a decision as to whether or not the sender is to be trusted (assuming a valid and acceptable signature).

It also means that corporate mail servers should perform validation PRIOR to any monkeying of the headers or the body. Whatever fragility can thus be mitigated.

While we're at it, how about RFC 2817 support? It allows an HTTP/1.1 connection to be upgraded to a TLS (SSL/HTTPS) connection AFTER the initial connection. This would allow web servers to use a single IP address for secure virtual hosts, which cannot be done currently via HTTPS. (Because the certificate is required in the HTTPS handshake, before the Host: field is provided, so the server cannot choose which certificate to present based on the hostname requested.) Adding this feature to browsers would release a lot of pressure on the IP address space utilization.

It will ask you what application you want to open this mysterious 'XHTML' document with if you try to send it something over HTTP using that MIME type, even though that is the correct and the ONLY correct MIME type with which to send XHTML.

This is not true. Refer to RFC 2854, which explicitly permits XHTML 1.0 to be labelled as text/html. Furthermore, it is also allowed to be labelled as applciation/xml and text/xml.

Since IE 7 renders XHTML fairly well with the SGML parser

That depends on your definition of "fairly well". In every single way in which XHTML differs from HTML, Internet Explorer gets it wrong. It doesn't even *attempt* to support XHTML. I don't think it's reasonable to consider that as rendering XHTML "fairly well". The only way it remotely acts differently for XHTML is Internet Explorer 7's new behaviour in not triggering quirks mode for the XML prolog.

all the developers really had to do was recycle most of the existing HTML rendering engine and the existing XML parser to produce an XHTML rendering engine

And doing it that way would lead to countless new bugs. It's a common misconception that XHTML is just HTML, but with mandatory errors on malformed documents. This isn't the case. XHTML has a different content model for some element types, it has differences in the DOM and it has differences in CSS.

If you want the developers to "just" recycle the existing HTML rendering engine, you are going to a) have plenty of places where HTML rules are used when XHTML rules should be used, and b) have plenty of regressions in support for HTML too. Catching and handling these bugs is a lot of work, especially when it's an old and crusty codebase like Internet Explorer's.

Internet Explorer 7 was a stopgap measure, not the place for extensive work like this. Version 8 is when they should implement XHTML support, then they at least have a chance at getting it right.

You're talking about format=flowed quoting as opposed to inserting line breaks. It has nothing to do with HTML. It's also arguably the right way to quote text. And it's a standard.

Not everyone's using an RSS reader from four years ago. =) Many RSS readers allow rendering of HTML. Heck, I'm using Bloglines, which is a web-based RSS reader; guess whether or not it supports HTML? However, it's up to the client to scrub the content properly and remove <script> crap.

Another question is, exactly how can you expect to launch an attack in a web feed? People use bazillion different RSS/Atom readers, and in many cases they're entirely separate from their web browsers...

Though, I hope people read the Atom spec if they're implementing it, scrubbing HTML content is specifically addressed in the "Security Considerations": "Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements might also have negative security properties."

I take your points about other areas that depend on IP addresses. The problem with multi-homing in IPv4 and IPv6 is that it makes it hard to scale the network - in fact, core routing tables started growing exponentially again in 2004 on the IPv4 Internet due to multi-homing (ref: http://en.wikipedia.org/wiki/Border_Gateway_Protoc ol). There is an IETF working group called Multi6 on IPv6 multi-homing for this reason, see http://www.ietf.org/html.charters/multi6-charter.h tml - not sure if their approach will simplify things for multi-homed sites but they are aiming to reduce core routing table growth.

Well we could put them to work as part of the backbone of the internet...

GET for idempotent requests (showing database records, search results, those kind of recurring, non-database-changing things) while POST should be used for things which actually change data, user state, and so on.

You are confusing idempotence and safety. "Idempotent" merely means that repeated requests have the same effect as a single request. You should use GET because it is safe, not because it is idempotent. For contrast, DELETE is an idempotent method, but it's certainly not a safe method. For some reason everybody seems convinced that "idempotent" is a fancy word for "safe". See section 9.1 of the RFC, it explains in more detail.

Using GET in the wrong places can lead to all kinds of irritations and miniature security problems.

The example you give for Slashdot highlights the difference between safety and idempotence. It doesn't matter if you make the request once or a hundred times, the result is the same - you are logged out. The request is idempotent. The problem is that it's not safe, because it alters application state by logging you out.

The example you give of sending an email is a bad one. Consider sending an email to the admin containing an iframe that generates a form and auto-posts it.

The correct way to guard against vulnerabilities like this is to generate a per-user nonce. Include it as a hidden field in every legitimate form and check for it in every form handler.

Unfortunately, I have to ding them on this - if the password is wrong, it hides the error message from you (you get something generic like "connection failed").

Well, yeah, but that's because it's Good Security Practice (TM). If J. Random H4x0r knew that the username was correct but the password was wrong, then he knows he's already halfway there. You're not supposed to give away that some of the information is right, but some is wrong. You're just supposed to say, "No. Try Again."

See, for example, IETF RFC 1939 section 13 (for POP3) and RFC 2060 section 11 (for IMAP4).

--Rob

Unfortunately, I have to ding them on this - if the password is wrong, it hides the error message from you (you get something generic like "connection failed").

Well, yeah, but that's because it's Good Security Practice (TM). If J. Random H4x0r knew that the username was correct but the password was wrong, then he knows he's already halfway there. You're not supposed to give away that some of the information is right, but some is wrong. You're just supposed to say, "No. Try Again."

See, for example, IETF RFC 1939 section 13 (for POP3) and RFC 2060 section 11 (for IMAP4).

--Rob

Your standards are obsolete.

Sigh... another troll, guess I got baited, but:

See, there's this thing called The Internet, and Google, and AOL, and CNN are all on it. We all agree that that thing is called the Internet.

On IPV6, there's nobody.

Who is this "we" that you are talking about? Obviously you are not on any IETF working groups as you are completely ignorant of the fact that IPv6 is a DOCUMENTED STANDARD that is ALREADY IS USE on the Internet! (See stupid comment about: "IPV6 is just a misnomer")

So it is obvious that you are not part of the "we" that "agree that that thing is called the Internet". You are just an end user, who knows very little about networking. Sit back and enjoy the ride, leave network engineering to those of us with a clue. When WE decide to move everything over to IPv6 YOU will follow. Or you can stop using the network, your choice really...

Oh, and if you bothered to do any research before opening your mouth and claiming Google is "on your side", you may want to check into the fact that Google already own IPv6 space!

Way to go cheese!

Sigh... another troll, guess I got baited, but:

See, there's this thing called The Internet, and Google, and AOL, and CNN are all on it. We all agree that that thing is called the Internet.

On IPV6, there's nobody.

Who is this "we" that you are talking about? Obviously you are not on any IETF working groups as you are completely ignorant of the fact that IPv6 is a DOCUMENTED STANDARD that is ALREADY IS USE on the Internet! (See stupid comment about: "IPV6 is just a misnomer")

So it is obvious that you are not part of the "we" that "agree that that thing is called the Internet". You are just an end user, who knows very little about networking. Sit back and enjoy the ride, leave network engineering to those of us with a clue. When WE decide to move everything over to IPv6 YOU will follow. Or you can stop using the network, your choice really...

Oh, and if you bothered to do any research before opening your mouth and claiming Google is "on your side", you may want to check into the fact that Google already own IPv6 space!

Way to go cheese!

Agreed. Even IP Datagrams on Avian Carriers is better in that category. But the bandwidth is definitely higher.

I thought gopher http://www.ietf.org/rfc/rfc1436.txt died a slow lingering death...

First of all, you can request more than one record at a time - the specification explicitly allows for more than one Question in the message.

If you're a server, what do you set RCODE to if one of the requests returns NXDOMAIN and the other returns a record? What if, instead of NXDOMAIN, you get SERVFAIL?

Having QDCOUNT>1 is ambiguous, and is basically a bug in the RFC. The author of MaraDNS did some research a while ago, and determined that no DNS server really supports it. I quote from doc/en/misc/multiple.qdcount in the MaraDNS distribution:

Neither DjbDNS, BIND, nor MSDNS support queries where QDCOUNT > 1. DjbDNS ignores queries where QDCOUNT > 1. Microsoft DNS server replies with a "format error", and the qdcount is set to the number of questions sent to the server. BIND 8 replies with a "format error", and QDCOUNT is set to zero.

Realistically, DNS servers should probably reply with "not implemented" instead of "format error".

Some discussion of the fact that QDCOUNT > 1 queries are not handled by modern-day DNS servers:

http://www.ietf.org/proceedings/98aug/I-D/draft-ie tf-dnsind-edns-03.txt
http://www.vpnc.org/ietf-ipsec/96.ipsec/msg00779.h tml
http://www.wcug.wwu.edu/lists/ipng/200005/msg00080 .html

In summary, the nitty gritty implementation details of handling multiple question queries in a single packet make this difficult to correctly handle.

I'm making the handling of multiple QDCOUNT queries a low priority in MaraDNS.

Of course, it would be possible to update the standards---and every existing DNS implementation---to support QDCOUNT>1 in some specific way, for this purpose, but by the time it's deployed, we probably won't care much about IPv4 compatibility any longer.

... but ISPs keep treating it like it is. If this kind of web-browser-error-messages-are-so-hard-to-understa nd-whaaaa-mommmy-hold-my-hand problem is so important, it can be done using proxying. Just have everyone who doesn't know how to type or can't understand the message "the domain ww.exampel.com couldn't be found" set the proxy settings in their browser. Or if you know your user base is composed of a bunch of idiots, use transparent proxying (obviously less effective with https traffic, but then significant changes to DNS, such as this is, effectively breaks https and what little trust you do get from https anyway). Can't proxy settings be served via DHCP or something too? This would provide all the advantages of dynamic configurations based on user/client machine (mac address) without even having to walk non-technical users through the process of changing their proxy settings in the browser.

On the other hand, if SRV records had been used initially to publicize HTTP servers, then only those records would need to be overloaded to provide this kind of service. At least then it would be restricted to DNS queries related to HTTP traffic, although still not ideal.

<link> is an 8 bit link number

I'm surprised his weblog doesn't have an Atom feed. His engineers must still be working on it...

There isn't any fundamental difference between software and malicious software that Windows can detect

http://tools.ietf.org/html/rfc3514

Nice to see that they forgot that the MIME type for JavaScript is "application/javascript"...

Forgot? The media types for JavaScript were only standardised this year. Before April, application/javascript was merely a common convention - and actually a less common convention than text/javascript, which is also an acceptable (if deprecated) media type for JavaScript according to the RFC.

So a) there wasn't anything to "forget", and b) they aren't doing anything wrong anyway.

You don't have to, even if there's no routing or DNS.

http://www.ietf.org/internet-drafts/draft-ietf-ipn gwg-icmp-name-lookups-15.txt

Once you are in full control of a user machine it is game over as far as any resources it accesses are concerned.

The reason is that ssh continues to be developed from the perspective "PAM sucks, we here do not do that". That is a purely political OpenBSD position which belongs to the realm of OpenBSD and should have nothing to do with OpenSSH.

I would imagine that the answer would be either with class="fn" or maybe class="nickname" since the hcard standard pretty follows the vcard standard: http://www.ietf.org/rfc/rfc2426.txt

What we really need is a DNS system that can return multiple IP addresses and a code to indicate how to use them (ie, randomly select one or use the first unless it fails then fallback to the next one).

RFC 2782. I quote:

The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.

It doesn't require any DNS infrastructure changes, but clients need to support it. For example, Firefox and Mozilla don't support it.

Well, you know.. Naughty bytes are only sent over networks with the evil bit set. Maybe we can have the same thing here; an extra evil-bit line added to every parallel bus on your system. For serial communication, we can stick with the old RFC.

Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.

All comparisons between character strings (e.g. labels, domain names, etc.) are done in a case-insensitive manner.

Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.

All comparisons between character strings (e.g. labels, domain names, etc.) are done in a case-insensitive manner.

You can get the internet delivered in tubes? I hope that's not on the CCNA exam, I don't remember that part...

Sure you can. Just have mice carry the packets. It's a simple extension of the IP over carrier pigeon protocol.

All in all Explorer sucks ass at file operations. You would probably get beter transfer rates with ftp.

If it's really that useful, Opera will have it integrated in 3 months time anyway ;-)

You laugh, but Opera for mobile phones already implements RFC 3966, which means you can click on a link in a web page to call somebody.

you click on a phone number in a web page and it calls it.

You still don't need to build the VOIP into the browser. Just a Greasemonkey script to convert plain-text telephone numbers into <a href="tel:..."> links and a handler to pass off tel: links to an external program just like mailto: links are handled.

RFC3546, section 3.1 specifies server name indication. mod_gnutls has supported it since April of 2005. mod_ssl (bug) is waiting on OpenSSL to make support possible. Opera has supported SNI since 8.0. IE7 has since beta 2. Mozilla/NSS/Firefox is ready to go with NSS 3.1.1/Gecko 1.8.1/Firefox 2.0. Konqueror will support it in 4.0 (bug). Safari is the only major browser without support (fresh bug).

This is easy. What you want are Avian Carriers. There is some latency possible, and inclement weather will lead to some potential packet loss, but it's definitely the best solution.

How about RFC 959 (FTP, dated October of 1985)?

One mode of operation explicitly outlined on page 9 transfers a file from one server to another under the control of a 3rd machine. The 3rd machine logs into both FTP servers. It initiates a passive recieve on one server and a 'normal' send on the other. The DATA (IP address and port) is passed from the reciever to the sender so that they form a direct connection with each other and complete the transfer.

If a bi-directional transfer is needed, just do that twice. The only difference is who initiates the transaction.

As others have pointed out, DCC also predates 1995.

It seems to me that we could eliminate a LOT of the patent morass if the USPTO was forced to bear the full weight of the messes it creates when it abandons it's responsabilities to the courts. That is, grant defendants in patent suits the right to sue the USPTO in cases where the patent shouldn't have been issued at all. Better yet, if the patent victem can present a document that was publically available (such as an RFC or other protocol description, freely available source code, a user manual, etc), USPTO pays treble damages. Damages shall include legal costs, any salery paid to other employees in support of the suit (or lost wages where an individual is kept from doing more profitable things while stuck in court), and any costs associated with damage control related to being named as a defendant in a suit that should never have happened.

Let that money come out of collected filing fees BEFORE any other disbursement. Once USPTO spends a year or two in the red, they'll start making dammned sure there isn't any prior art before they grant a patent.

Exterior Gateway Protocol http://tools.ietf.org/html/904/ (1984)

The data is stored in a tree structure: you ask information about your siblings from your parent, just as you do in the net2phone patent.

Except Adobe granted everyone a patent license to use those patents. It's right in the PDF specification you can download from Adobe.

If you don't want to download that, which is kind of big, you can also read it in this short text document.

This article is useful in that it gets people thinking about the problem. Now some clever person can come up with a proposed solution and post an article about it. That's how it works.

It's not like nobody's ever discussed these issues before. Or have they?