RFC: HTTP status 462 (Out For Lunch)

Independent Submission                                   Marko Oikarinen
Request for Comments: 79O6                                     Sysart Oy
Category: Informational                                     1 April 2016 

   The Hypertext Transfer Protocol Status Code 462 (Out For Lunch)


   This document specifies a Hypertext Transfer Protocol (HTTP) status
   code for use when a human-backed server resource is unavailable as a
   consequence of said human participating in a process of consuming
   nutritional substances.

Status of This Memo

   This Internet-Draft is not submitted.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 1, 2017.

Copyright Notice

   Copyright (c) 2016 The persons identified as the document authors.  
   No rights reserved.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3. 462 Out For Lunch . . . . . . . . . . . . . . . . . . . . . .   3
   4. Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5. International Considerations  . . . . . . . . . . . . . . . .   5
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7. Appendix A. Acknowledgements .  . . . . . . . . . . . . . . .   6
   8. Author's Address  . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

   This document specifies a Hypertext Transfer Protocol (HTTP) status
   code for use when a server operation internally utilizes a resource
   implemented in flesh and bone and said resource is currently having
   lunch or is in a post-lunch RESTful state, therefore unable to 
   provide the required resource, thus forcing the server to deny 
   access to the resource or to a set of resources which includes the
   requested resource.

   This status code can be used to provide transparency in circumstances
   where service availability may affect client operations. This
   transparency may be beneficial to end users.

2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "APRIL", "FOOL", and "DESSERT" in this
   document are to be interpreted as described in [RFC2119]. 

3. 462 Out For Lunch

   This status code indicates that the server is denying access to the
   resource as a consequence of a required human dependency having
   lunch. This status code is not to be confused with status code 
   "461 Out To Lunch" which has to do with server behavior under the 
   influence of cosmic rays when financial considerations have made the
   administrator decide against investing in error-correcting (ECC)
   server random access memory. 

   A human backed resource may be manifested in ways including but not
   limited to: a senior dead-tree archive manager, a microfilm squinter,
   an adidas conveyor, a ticket pusher or a ticket dodger or a
   Just-In-Time (JIT) backend feature developer.

4. Security Considerations

   Server resources addressed with the "coffee:" URI scheme as specified
   in RFC2324 MUST NOT return status code 462, as a HTCPCP/1.0 (Hyper
   Text Coffee Pot Control Protocol) device is expected to be autonomous
   and not utilize humans in its implementation. Such HTTP responses are
   to be considered potentially malicious.

   Clients cannot rely upon the use of the 462 status code. It is
   possible that certain resources utilized by the server might wish to
   avoid transparency, and not disclose that they have left the premises
   in order to dine at the local gentlemen's club.

5. International Considerations

   The use of the 462 status code implies temporary unavailability of
   the resource named in the request. It is expected that a later
   request for the resource may succeed if the resource has recovered
   from the digestive condition.

   When an attempt to access a resource fails with status 462, it is to
   be expected that the recovery time of the server is highly locale
   dependent. In a worst case scenario the situation might involve a six
   course meal with DESSERT and a post-nourishment RESTful period also
   known as a siesta.

6. References

6.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2324]  L. Masinter, "Hyper Text Coffee Pot Control Protocol
              (HTCPCP/1.0)", RFC 2324,  1 April 1998,

7. Appendix A.  Acknowledgements

   This document was inspired by RFC 7725 by Tim Bray and borrows some 
   phrases from it with minor adaptations.

8. Author's Address  

   Marko Oikarinen
   Twitter: @whoman4says
   Blog: https://scribblelayer.com/
   Employer: http://sysart.fi/

Enterprise DevOps

I type the program arguments into an Excel sheet. I write a short description of what I am trying to accomplish. I send the description and the Excel sheet to a person that has access rights to the ticketing system. Repeat three times. The next day she reads my emails and submits the three tickets.

The three tickets get assigned to three persons in a country where work used to be cheaper than here. They type the program arguments from the Excel sheet into the scripts that will run the programs. They mark the tickets resolved. Corporate metrics show exemplary ticket handling response times.

Next week another ticket gets resolved and a tester gets access rights to the system. She runs a test case for my use case. It doesn’t work. I request access to the log files from the server admin. Next day I have the logs and find out that the second script failed to trigger the third script due to file access rights. No problem, that is easy to fix.

I write a short description of what I am trying to accomplish. I send the description with an Excel sheet to a person that has access rights to the ticketing system. I realize that this is state of the art in Enterprise DevOps in 2016.

Scribble Layer – beyond the model

In the fall of 2010 we at Sysart organized a small conference at Helsinki and Oulu. Daniel Wellner and I did our presentation on how to keep the domain model unambiguous. Jimmy Nilsson was the featured guest and talked about building a domain model.

In his presentation Jimmy said something that caught my ear: “The user should be able to save invalid data“. The concept is explained in chapter 7 of his book Applying Domain-Driven Design and Patterns. The book says: “All States, Even When in Error, Should be Savable”. The idea is simple but not widely applied – when a user cannot complete all the required information the application should still allow saving the partial work he or she has done.

The concept stuck in my mind. Every now and then a situation comes up where this idea seems to fit. Think of a doctor entering a diagnosis into a patient care application. A diagnosis entry form might contain a dozen fields. It would seem useful that the doctor could enter just the most important data while with the patient, save the entry and complete it later. But applications tend to be too eager and demand everything to be completely valid on first save.

Then I stumbled upon StaffPad. StaffPad is an application for writing music. Writing music. Not typing, not mousing around. Writing music the old-fashioned way, with a pen. As a songwriter I was immediately intrigued. Could this application make notating random ideas into a computer feasible for me? I always preferred pen and paper because I disliked the input methods in all the music applications I tried.



The pen works really well for entering notes, rests and other symbols. But what happens when StaffPad does not recognise your writing? It applies Jimmy’s advice and saves the unrecognized strokes as part of the page. If you print the score, the mystery symbols are not discarded, they get printed too. A human can read and play the scribbles assuming your handwriting is legible. The only thing StaffPad cannot do is play the notes because the meaning of the unrecognized strokes is a mystery to the application.

This is good, but StaffPad takes it a step further. Sometimes the user wants to express something that can not be codified in the domain model. Western musical notation has a huge amount of symbols and it is not feasible to implement all of them in an application. StaffPad has a clever way around this problem: an extra layer (think Photoshop layers) on top of the notation where you can draw whatever you like. A scribble layer. You can jot down obscure electric guitar performance symbols or draw a picture of your favorite game character. The layer is domain-aware – it intelligently attaches to bars, and is formatted into each musicians parts on printouts.


Is this idea of a separate unstructured layer placed on top of the model presentation useful in other applications? I sure would like to annotate source code with small drawings in my IDE and have them follow the source anywhere it goes. Do you know applications that implement a similar idea?



Samplitude on a tablet – part II

This is part two in the adventure where I’m experimenting with using my DAW on a tablet with only a touch interface. See here for part one: Samplitude on a tablet – part I

I believe I have found the most productive combination of toolbar buttons. I have also updated the Thinkpad tablet to Windows 10 and everything still works smoothly.


This is the set of toolbar buttons I settled on. These actions are optimized for recording and arranging song ideas, not mixing. There are 18 buttons:

  • toggle drawmode – shows/hides track control panes
  • show/hide track editor – edit a single tracks properties, access to plugins
  • show/hide mixer
  • group objects
  • ungroup objects
  • toggle snap
  • undo
  • split object
  • remove range
  • zoom=10s
  • zoom=60s
  • lock all audio – Prevents accidental moving of objects. With a keyboard I use shortcuts to toggle the Lock/Unlock  state of individual objects. With touch it is easier to have a single global lock.
  • cut – Normally I ctrl+drag objects to copy them but cut/copy/paste works better with touch.
  • copy
  • paste
  • toggle metronome
  • rec
  • play/stop

The Windows task bar is back at the bottom of the screen and hidden. Swiping up from the bottom shows the task bar and gives access to the touch keyboard.

If you use multiple time signatures like I often do, I recommend setting the project time signature to 1/4 or 1/8 and NOT adding any signature changes. This makes it easier to move song sections and parts around.

Samplitude on a tablet

Samplitude Pro X2 was recently on sale for a ridiculously low price so I decided to grab a second copy. My studio DAW has Samplitude tied to a dongle for historical reasons so it was nice to get a dongle-free license for mobile use.

So… I’m wondering if Samplitude would be usable on a Windows tablet? I don’t like using a computer for songwriting and demoing, there is enough mousing and typing during the day already. Could a tablet provide a more organic and fun experience somewhat like a 4-track cassette portastudio back in the day?

Inspired by surfaceproaudio.com I decided to try it. I’ve installed Samplitude Pro X2 and ASIO4ALL on a Thinkpad Helix tablet and I’m in the middle of figuring out the workflow and settings that make this possible. Touch only – no keyboard and no mouse! This is a work in progress but so far things look very promising!

Sam Pro X2 tablet

To maximize the space for manipulating audio, I have removed all the visual elements that are not absolutely essential. The Windows 8.1 task bar I’ve moved to the left side of the screen to free some vertical space. The onscreen keyboard is accessible from the task bar all the time. Naming tracks and saving files still requires some typing. I’m trying to fit the frequently used actions on a single toolbar so I’ve removed the toolbar at the bottom. Samplitude has a Big Toolbar option which makes the icons just the right size for touch.

The toolbars can be customized to contain exactly the buttons you need. There is a default palette of commonly used toolbar actions. In addition, any action that can be found in the menus can be added to the toolbar with the custom button. This kind of customization is essential for usability in any software.

Sam toolbar custom action

The arrangement (VIP) window supports touch gestures. I can scroll the timeline, pinch-zoom, marquee-select objects, select a range, move the play cursor – all without buttons.

There are some essential actions still missing from my toolbar. I can select and split objects but have no way to delete or mute them… doh! I guess I’ll remove the zoom and navigation buttons to make room for those.

Garbage in – default out?

We were freshly into production with this system that had a lot of moving parts. The whole system consisted of several big monolithic applications and half a dozen newer microservice-style services integrated into a “living organism”.

A user was not getting the results she expected. We investigated the problem and found out that a service we were calling was not returning some of the data we were interested in. In particular, data older than three months was not seen by us. A support person for the service said: ‘you should use wide search if you want to see the older items’. But wait – we were using wide search, always had been!

I double-checked the code and sure enough, it did say widesearch=”true”. Strange. So I blew the dust off the API spec and found this: widesearch=”1|0”. Yikes, the value should be a number! And I had coded this, totally my bad. I guess I’ve grown too used to using true and false for boolean values in XML. We were a month into production when we found out we were not using wide search. Never had been!  

Why did we not get an error when we called the service with bad parameters? 1 and 0 look like numbers to me, but the service had been happily accepting the string “true” all along. I decided to run a little experiment against the service in the test environment:

<request key="..." widesearch=”anything goes?” />
<response>OK ...valid search results...</response>. 

Okay, so it seems there is no validation of the parameter whatsoever. The code probably reads something like this:

if("1".equals(request.attr("widesearch")) ...

Why did we not find this bug during testing? This integration point was hammered a lot because during the project there were a lot of version updates on both sides of the API fence. Before going into production, the integration was in use for at least half a year in the testing environment. Somehow we just managed to not hit the three-month limit. For us ‘widesearch’ was just a mandatory constant we had to set in the API, not a thing that would be interesting to test.

Now, imagine that the service actually checked that the parameters in the API call have correct data types. We would have found our bug on day one of testing. Actually earlier – the first time we tried to call the test service. Silently choosing a default when the input is garbage does a big disservice to making the whole system robust.

When computers talk to computers it is better to be strict in the protocol. Problems get flushed out way quicker.

Large systems… designed?!?

In his excellent talk on DDD & Microservices Eric Evans had a slide that said “Not all of a large system will be well designed”. Yes, that does match my experience with software systems very well. However, I originally misread the sentence as “Not all large systems will be designed”. I think the misread version sounds true too. I can certainly state with confidence that “not all large systems were designed”. That is because they just happened 🙂