Slashdot Mirror

I remember stating that originally, an indication of which network protocol to use was meant to go between the slashes.

I don't think so, since the double slashes only apply to Internet schemes anyway. RFC1738 says:

//<user>:<password>@<host>:<port>/<url-path>

      Some or all of the parts "<user>:<password>@", ":<password>",

      ":<port>", and "/<url-path>" may be excluded. The scheme specific

      data start with a double slash "//" to indicate that it complies with

      the common Internet scheme syntax.

But if you find another reference, please let me know.

The only place where I know of that being used is in AFP URLs where you can specify AppleTalk using the following syntax: afp:/at/[user[;AUTH=uamname][:password]@]servername[:zonename]/volume

This is referred to in:
http://tools.ietf.org/html/draft-ietf-svrloc-afp-service-01
as well as:
http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes

You're *deploying* behind NAT? Just get enough IPs to run your sites and stop being a cheapskate.

I administer roughly 32k IPs in about 40 aggregates that we advertise via BGP. I have customers who occasionally come to me with this kind of scenario, yes. Often that's an upgrade from a SOHO firewall to pfsense, since most of the SOHO stuff can't handle more than one IP (note: I'm pointing out now how we benefit financially by selling more services with the existing HTTPS limitations, even as I'm arguing they are wasteful of the larger shared IPv4 resources).

As a service provider, I dislike having to provision a unique IP for each SSL website we host, because it is wasteful (though, again, profitable too). It could have been done with SRV records, but that wasn't an option until Feb 2000.

I'm a year older than the Internet. Hopefully we'll get to IPv6 before I hit retirement. I'm not holding my breath.

Okay, so noone uses them, but TBL's own RFC in section C.1 demonstrates the use of an initial double-forward-slash meaning change the netloc without changing the protocol. This could be useful if you're dealing with resources that have the same mapping on multiple protocols (like http and https). I know it's a corner case, but it is still technically a documented use case...

You may be right about SSL, but I think you're incorrect about encrypted Email. PGP was a very easy-to-use program for its time, complete with plenty of documentation that (as a previous poster mentioned) posed the problems and solutions in clear, Alice-and-Bob terms.

Furthermore, the PGP/MIME standard was very clear, and had a clear RFC. I implemented this RFC myself for two different email systems over 10 years ago. Nevertheless, PGP/MIME didn't catch on, and I myself rarely use it now.

Why? Part of it was FUD with S/MIME, but mostly it's just critical mass I think—anything that takes more than a few minutes total won't be done by most people unless it averts an immanent catastrophe (and sometimes not even then).

You mean, something like RFC 4255, the SSH key RRTYPE? Such a beast has been proposed in the IETF dnsext WG, current status seems to be withdrawn pending further work, as of July this year, but I haven't seen it re-submitted. The agenda for IETF 76 in early November isn't set yet, but alas, both pkix and v6ops conflict with dnsext, so I am likely to miss that session.

(Might be worth trawling the mail archive for dnsext on this subject here).

You mean, something like RFC 4255, the SSH key RRTYPE? Such a beast has been proposed in the IETF dnsext WG, current status seems to be withdrawn pending further work, as of July this year, but I haven't seen it re-submitted. The agenda for IETF 76 in early November isn't set yet, but alas, both pkix and v6ops conflict with dnsext, so I am likely to miss that session.

(Might be worth trawling the mail archive for dnsext on this subject here).

I think IPv6 is going to end up as another VCD (Video CD). That is, a pre-mature solution that won't ever actually see wide-scale adoption, but will merely fill the space until the _real_ solution is invented (out of genuine necessity).. which will probably be widely adopted quite quickly.

It will only be another VCD if another technology comes in and trumps it. In the case of VCD it was trumped by DVD, because which ever way you look at it there was always a need for something better than VHS. In the case of IPv6 it provides solutions to the problems we have today. The problem we have are people trying to implement IPv6 solution using approaches designed for IPv4, such as NAT or DHCPv6, or just aren't waking up and smelling the coffee. Its not happening faster because many people don't want to put the time or effort into it. If you are upgrading hardware, why not make sure that IPv6 is basic functionality that you can activate when your upstream provider provides it.

If you look around implementing IPv6 is not complicated, but it is complicated while important parties are playing their part.

I have been using IPv6 for the past two years and have learnt about it. What I have learnt is that in North America we are dragging out feet big time and the only workaround is using IPv6 tunnels. I have used a mixture of Teredo, SixXS, Freenet6 and the Apple Airport Extreme, depending on where I am. One thing that surprised me is that IPSec was originally an IPv6 technology 'back ported' to IPv4. In France Free.fr already provides IPv6 to its customers and apparently used this technology to make it happen:

http://www.ietf.org/id/draft-despres-sam-03.txt

I have an RSS reader that does the same thing. Except that if the interesting person has more to say than 140 characters I can read that too.

I don't think anyone should be allowed to post to Slashdot if they can't figure out how to encode arbitrarily large content into 140 characters. Hint: http://www.ietf.org/rfc/rfc2396.txt

Second Life is a lot more flexible though, when it comes to user generated content focus it's probably the pinnacle. LBP has the reduced scope by far in this regard. Plus, with efforts like OGPX/VWRAP it's actively expanding and becoming interoperable/decentralised with the assistance of the original innovator, hopefully negating the negative effects of this platform being controlled by one entity, what are the chances of this happening elsewhere?

The Secure Remote Password protocol (SRP) solves all 3 of these requirements by proving that the server and client both agree that the other one is in possession of a shared secret without ever revealing that secret.

Support in SSL/TLS was standardized as part of RFC 5054.

• Wikipedia entry
• White paper, source code

Oh, wait. Do monkeys live for 1000 years?

Hey, you could at least bother to read the RFC before asking such a pointless question! RFC 2795 handles such things transparently. Under the hood you'd see:

            BoBoSIM> SEND FOOD
            SanDiego> ACCEPT
            BoBoSIM> SEND MEDICINE
            SanDiego> DELAY
            BoBoSIM> SEND VETERINARIAN
            SanDiego> REFUSE
            BoBoSIM> SEND VETERINARIAN
            SanDiego> REFUSE
            BoBoSIM> NOTIFY NORESPONSE
            SanDiego> ACCEPT
            BoBoSIM> NOTIFY DEAD
            SanDiego> ACCEPT
            BoBoSIM> REPLACE MONKEY
            SanDiego> ACCEPT

But the ZOO abstracts all that so you don't have to care.

I'm not sure how many programs do it. It's in the RFC though.

Identifying UTF-8 is still reasonably easy. If the file contains none of the codes which are disallowed in UTF-8, and never has a lone byte whose code is above 0x80 surrounded by codes below 0x80, it's almost definitely UTF-8.

IPv7 was specified in 1993:
http://tools.ietf.org/html/rfc1475

There will likely not ever be an IPv7 release, because the IPv7 protocol one of the proposals a long time ago as the protocol designed to replace IPv4.

RFC1475, TP/IX: The Next Internet

The version number has been spent.

That is, unless the IETF continues the work on that protocol and implementations are made in such a way that it supercedes IPv6. Still... after upgrading to 128-bit addresses, people are unlikely to want to downgrade back to 64-bit IP addresses.

It's funny though:

2.1 Is 64 Bits Enough?
Consider: (thought experiment) 32 bits presently numbers "all" of the computers in the world, and another 32 bits could be used to number all of the bytes of on-line storage on each computer. Most have a lot less than 4 gigabytes on-line, the ones that have more could be notionally assigned more than one address.)

Of course ultimately they missed the point that IP addresses have structure to them. Address spaces get divided into networks.. Having enough addresses for all hosts doesn't necessarily prevent shortages, if the networks aren't divided along the right lines.

Also, if the networks are divided at too small a level, you get fragmentation, and routing table explosion.

But then all that's why IPng became IPv6.... as far as V7 was concerned, good riddance :)

An all-too-quick 40 minutes? At a user/usage level? There's a LOT to choose from, but as a great start, try RFC2504. http://www.ietf.org/rfc/rfc2504.txt?number=2504 Pick and choose as appropriate to your needs. We tried to make it very useful as a reference for the generic user. You can even hand out copies if you like. For a bit more detail, and as a good read in case you get asked some lower-level questions, try RFC 2196, more specifically targeted for IT folks, and "Middle Managers" who have to at least be exposed to the concepts. http://www.ietf.org/rfc/rfc2196.txt?number=2196 Cheers, Steve PS(don't let the fact that these are TEN years old fool you, most of these concerns are still quite current, most companies (read: those of popular OSes) don't exactly *want* people to understand the why's because they start to question the why-not (yet)s. If you found any of this useful, or not, just reply here, Most if not all those email addresses are defunct at this point -- we've moved onto and into other things).

An all-too-quick 40 minutes? At a user/usage level? There's a LOT to choose from, but as a great start, try RFC2504. http://www.ietf.org/rfc/rfc2504.txt?number=2504 Pick and choose as appropriate to your needs. We tried to make it very useful as a reference for the generic user. You can even hand out copies if you like. For a bit more detail, and as a good read in case you get asked some lower-level questions, try RFC 2196, more specifically targeted for IT folks, and "Middle Managers" who have to at least be exposed to the concepts. http://www.ietf.org/rfc/rfc2196.txt?number=2196 Cheers, Steve PS(don't let the fact that these are TEN years old fool you, most of these concerns are still quite current, most companies (read: those of popular OSes) don't exactly *want* people to understand the why's because they start to question the why-not (yet)s. If you found any of this useful, or not, just reply here, Most if not all those email addresses are defunct at this point -- we've moved onto and into other things).

The two main wireless protocols in contention for use at the home level are 6LoWPAN ( http://www.ietf.org/html.charters/6lowpan-charter.html ) and ZigBee Pro ( http://www.zigbee.org/ ). ZigBee is the much more interesting network for this application

Pff. Wireless is where it's at...

There are two D-Link models that support IPv6. However, the standard for IPv6 home routers has not yet been finalized: http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ipv6-cpe-router/

... when I had to move this RFC to the "useful RFC's" bookmark folder

Don't forget QoS

Also for reference, the .edu namespace is neither older nor newer than the other generic TLDs. They were defined in October 1984 in RFC 920.

We don' have software patents over here, but It's a subject that I fallow regularly here on Slashdot. I found this analogy about English prose one of the bests I saw to inform non computer literates about this subject.
Take my example. I'm currently writing an FTP client for learning and contribute purposes. One of the things about FTP is that each server vendor as some kind of slightly different application. So if I want to make a client that has some kind of success I have to test many of the servers(closed sourced and open) out there, so my program can parse every line. I've mostly wrote this software from scratch fallowing the RFC specifications.
At some point I've downloaded the source code of some popular open-source FTP clients(FileZilla, KFtpGrabber), to analize the code and look for different approaches. It was surprising to see that while both this programs and mine are very complex applications, and that my work is completely original, we have very common programming techniques(and code) on several identical subjects(even the variables have the same name sometimes).
What I've realize is that for some problems there are out there have just about one or two best solutions. No one can argue that my creativity is not original. I've only looked at the code of these programs after the engine was almost written, but hypothetically if at any point some FTP client program or idea was patented my program wold violate that for sure(although it would not violate copyright since it's not the same code).

Patenting code is like patenting solutions to problems and it could be justified if there were many different solutions out there but the reality is that many problems have only one or two correct approach.

RFC 1178: Choosing a Name for Your Computer, http://www.ietf.org/rfc/rfc1178.txt
RFC 2100: The Naming of Hosts, http://tools.ietf.org/html/rfc2100

RFC 1178: Choosing a Name for Your Computer, http://www.ietf.org/rfc/rfc1178.txt
RFC 2100: The Naming of Hosts, http://tools.ietf.org/html/rfc2100

RFC1178 still contains some useful advice.

That is a problem that may be getting corrected by the ITR :)

FTFY

That is a problem that may be getting corrected by the IANA TLA registry :)

First off, port 53 is NOT being redirected. Use your choice of port 53 provider - whether your own DNS, Level 3, OpenDNS, whatever. As for how it works, check out http://networkmanagement.comcast.net/DomainHelperLogic.htm and http://tools.ietf.org/html/draft-livingood-dns-redirect-00 for the precise details. The second document is a complete technical description.

Most of the things you ask about can be done with CSV as long as it's quoted properly. If it's not quoted properly, then it would be considered invalid. There's a nice RFC spec for it here: http://www.ietf.org/rfc/rfc4180.txt

What happens when your data contains \r or \n characters?

It's perfectly acceptable as long as you quote it (#6 example of RFC 4180). If Oracle doesn't support that, then I would say their implementation is broken.

What happens if the data has commas in it, and the .csv was generated by something that doesn't add quotes?

It's invalid

What do you do if your data is more complicated than a simple table?

I'd need a better example from you, but you can embed a csv record inside a csv field. It starts to get complicated really fast with all the "escaping" that needs to be done with the double-quotes. Such as something like a record containing "Last Name","First Name","Sub-Properties". The Sub-Properties could be embedded data such as sex, age, and height. For example:

"Doe","John","""male"",42,""5-10"""

Clearly, you can represent tree style data with CSV, but it has more flexibility than you think. Too many people roll their own CSV, because it seems so simple. Then they don't quote and escape quotes properly blaming any issues on garbage data.

Except CSV isn't a standard.

The IETF might disagree with you.

"This memo provides information for the Internet community. It does not specify an Internet standard of any kind. "

Except CSV isn't a standard.

The IETF might disagree with you.

Bell Canada's engineers should read draft-livingood-dns-redirect-00 which if nothing else explains how bad their implementation is.

While there isn't consensus on where to go with this draft. The is consensus that cookies don't work and that NXDOMAIN rewrites are different in nature to the other forms of redirect in draft-livingood-dns-redirect-00 and should be treated as a separate issue to the other forms of redirect.

This is being discussed in the dnsop working group.

Bell Canada's engineers should read draft-livingood-dns-redirect-00 which if nothing else explains how bad their implementation is.

While there isn't consensus on where to go with this draft. The is consensus that cookies don't work and that NXDOMAIN rewrites are different in nature to the other forms of redirect in draft-livingood-dns-redirect-00 and should be treated as a separate issue to the other forms of redirect.

This is being discussed in the dnsop working group.

It's simple! Just set your firewall to filter the evil bit! Everybody knows that!

And now you have confused people even more. First, implicit FTPS is deprecated. Explicit FTPS is what is being used and implemented. It is what is described RFC 4217. It is what I used in my open source FTPS library and client. Works great.

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

Need more: read here. http://en.wikipedia.org/wiki/FTPS#Methods_of_Invoking

http://www.rebex.net/secure-ftp.net/

It is so confusing I get confused and I have implemented these protocols. The mistake I made in my earlier post was referring to implicit FTPS as the the other mode of explicit FTPS where the user is allowed to turn the tunnel on and off. That is actually referred to as a name which escapes me.

http://www.rebex.net/secure-ftp.net/

Second, for every passive connection you most certainly have to handshake that connection. Certs are passed on the connection and the tunnel is set up each time a file is transferred. It might appear to you as a user of an FTPS client that isn't happening but I assure you it is.

So get off you high horse my little MVP friend and do some implementations and less blogging.

Also, despite the bad form of replying to myself, I found the RFC's specifying the protocols here: RFC 4838 (DTN) and RFC 5050.

Also, despite the bad form of replying to myself, I found the RFC's specifying the protocols here: RFC 4838 (DTN) and RFC 5050.

i was thinking the serial number from the gov is an ok idea if they would change it to 32 bit notation and make it rout-able....

instead of 123-45-6789 I could have 172.31.20.12 or whatever. (Yes I know that is private space.)

You should look at the EDIINT AS2 protocol, AKA RFC 4130. This is a widely-used e-commerce protocol built over HTTP/S.

AS2 provides cryptographic signatures for authentification of the file at reception, non-repudiation and message delivery confirmation (if no confirmation is returned, the transfer is considered a failure), and is geared towards files. There is even an open-source implementation avaliable.

More complex than FTP/SFTP but entirely worth it if your data is mission-critical and/or confidential. Plus, passes through most networks because it is based on HTTP.

Sorry, section 8.1.4. I was looking at the draft of the RFC to replace RFC2616 rather than RFC2616 itself when I wrote this.

I'm further thinking that since this is such a stupidly trivial attack, that it was all that MS could think to defend against, and that no Apache developer believed that any self respecting attacker would stoop so low.

Or maybe they're relying on the attacker correctly setting the evil bit as per the specification, while Microsoft is flagrantly ignoring the spec as usual.

Just to clarify the bit about the addresses, because I forgot a couple of sections...

The whole IPv6 address is 128 bits, but in a unicast address, the first 3 are the "prefix identifier," basically saying that this is unicast. Then you have a 13 bit "TLD Identifier" and 8 reserved bits, completing the global prefix portion.

But then you have a 24 bit "NLA ID", which might specify an ISP or some other intermediate network. This provides for traffic aggregation, and they get assigned (I guess) by the national registries. This brings you to 48 bits. Exactly how they'll choose to distribute the NLA IDs, and how many each organization/ISP will get, I'm not quite clear on. I've heard some people allude to ISPs getting large blocks at this level and putting a "subscriber ID" or "customer ID" in this region, leaving 80 bits free per customer, but I don't think this is really the case.

After the NLA is a "SLA ID", which is like a very big subnet identifier. It's 16 bits long, bringing you to 64 for the address so far. This is what I think individual home routers will get from ISPs, assuming the NLA IDs get given out with enough granularity so that there isn't competition.

Beyond the SLA ID is 64 bits for the "interface ID," which a host can pretty much define however it wants. In most applications this can be easily created by padding out the Ethernet MAC, although it can also be generated randomly if that's not desired.

References:
http://technet.microsoft.com/en-us/library/cc757359(WS.10).aspx - Surprisingly good TechNet article
RFC 2462

The IETF has been conducting code sprints for a few years now, typically just before an IETF meeting. The next one is July 25th in Stockholm.

These are used both to get some useful tool development, and to get programmers interested in the work of the IETF. My understanding is that they have worked out pretty well, with a dozen or so people showing up for the San Francisco code sprint.

Microsoft actually contributed lots to HTML 5, at least according to Chris Wilson (Software Architect for IE)

Someone had to introduce problems, incompatibilities, and inconsistency or it wouldn't be a proper standard.

When you say "HAD TO" what exactly do you mean?

Just make this a required feature: OP

We need a 'djb' tag. Dan's been talking about, and working on this kind of thing for years.

If 'this kind of thing' means DNSCurve rather than DNSSEC then sure, you are dead on! But rather we can see that DNSCurve != DNSSEC. DJB is, as usual, thinking that his idea's are better than an entire consortium and I'm sure that we will see him continue to break RFC at his whim because he simply does not understand, he thinks that he is better than others or some magical being had tapped him on the shoulder. Maybe you should take a trip back in a TARDIS to last year?.

I know... I know, don't feed the trolls.

"Openly malicious" is really tricky - I'll grant you that.

Nah just check the evil bit. That's what RFC3514 is for!

zigbee was fine in certain circumstances, but has largely been superceded by IPv6 over Low power WPAN aka 6lowpan Two major advantages of 6lowpan are that it is more or less regular Internet (TCP/IP) the other is that, as a result, more secure and almost infinitely more scalable.

Additionally, zigbee is not a standard, 6lowpan is. That difference has important repercussions for long term planning of projects. The IETF has a good track record for standard maintenance. There are also GPL tools for 6lowpan devices.

6lowpan is more flexible. Unlike zigbee, which is fine in some contexts, 6lowpan works with a variety of wired and wireless, low-power, low-bitrate transmissions.

The Internet is where things happen nowadays. 6lowpan is part of that.

Today your web browser always hits the remote server first, even if you already have a cached copy of the content. It's checking to see if its cache is still valid. If the site is down, you see an error (read: your app won't run); if the site decided to delete or change the content, your browser obliges and caches the new version, whether you wanted the old version blown away or not.

New to the WWW? Homework for tonight: http://www.ietf.org/rfc/rfc2616.txt