_mhp_

You don't have to use your personal email address in commits if you wish to keep it private on GitHub:

https://help.github.com/articles/about-commit-email-addresse...

Kevin Igoe is retiring next year, and is currently handing over to the two new CFRG chairs. They introduce themselves here:

http://www.ietf.org/mail-archive/web/cfrg/current/msg04552.h...

http://www.ietf.org/mail-archive/web/cfrg/current/msg04553.h...

Another alternative is minion[0]. The format is TCP on the wire which avoids the NAT problems that SCTP has, but it is able to deliver some really interesting features, including multiple message streams like SCTP.

[0] https://datatracker.ietf.org/doc/search/?name=minion&actived...

There is no actually secure - that's the problem. The best you can do is secure against specific threat models. Up until recently, most people didn't necessarily view government intrusion as a particularly credible threat, so didn't spend the extra time/effort/money mitigating against it.

One of the best things to come out of all these revelations, in my opinion, is a revised view of what threats we should consider which were previously dismissed as paranoid ramblings.

I paid with a debit card - transaction went through and I have an email confirming my order.

$location: I am in you.

I wondered why the article didn't mention JANet-style addressing, or UUCP-style bang-paths, both of which lead to more specific elements on the right.

With the rise of NAT-traversal technologies, I find it a little disappointing that bang-path addressing hasn't been rediscovered and used with TURN.

Yes. A substantial fraction of the upper classes are quite poor, for many reasons, not least the rising costs of maintaining a family home. Some even turn to TV to help defray the costs, such as Francis Fulford in the series 'The F*ing Fulfords' (http://en.wikipedia.org/wiki/The_Fucking_Fulfords). You can probably find clips on Youtube.

Section 2 contains:

  A PATCH request can be issued in such a way as to be
  idempotent, which also helps prevent bad outcomes [...]
  Clients using this kind of patch application SHOULD use
  a conditional request [...]  For example, the client
  can use a strong ETag [RFC2616] in an If-Match header on
  the PATCH request.

I've found it useful as a basis for handling HTTP requests in a test framework I'm working on. Not for testing HTTP, mind you, just as an adjunct for other tests. The 'one header line per packet' responses are a little idiosyncratic though!

Isn't that one of the arguments in favour of Lisp and similar languages? That the information density is so much more conducive to writing expressive code that is still sufficiently concise to keep in your head whilst writing it?

I have got experience of DSP assembly (mostly 320C25 stuff, a little 'C50), and I initially doubted the story. DSPs like the 'C25 were pretty easy to work with since the instructions were all the same length (ignoring memory wait states for the moment). But with the 'C50 (and the 'C30 from the article), delayed branching was introduced. Whilst you can optimise for that in your head, it becomes a pain and often results in hard-to-maintain code. Adding a couple of NOPs makes it much easier!

The article highlighted common sub-expression elimination too, which again can be done manually. But (and this is the crux IMHO) writing optimal code continuously at this level is mentally tiring (leading to bugs) and often gives brittle unmaintainable code. A compiler never needs to worry about this as it generates fresh code every time rather than maintaining the code from the last build. But a human will learn to avoid brittle code and hence won't be able to take advantage of the possible optimisations.