rfc27: document job feasibility service

Problem: The feasibility service, through which the satisifiability
of submitted jobs may be determined out of band, is not documented.

Add a Feasibility section to RFC 27 describing an optional feasibility
service.

spec_27.rst

@@ -99,6 +99,8 @@ Design Criteria
 
 - Allow the expiration time of a resource allocation to be adjusted.
 
+- Allow out of band detection of unsatisfiable job requests.
+
 Implementation
 **************
 
@@ -644,3 +646,29 @@ a ``sched.free`` request.
 
 If the scheduler is monitoring job exceptions, it SHOULD NOT react in ways
 that might conflict with the job manager's actions.
+
+Feasibility
+===========
+
+A scheduler or other entity MAY register a generic ``feasibility``
+service name through which the feasibility or satisfiability of jobs may
+be determined out of band, for example during job submission.
+
+The ``feasibility`` service MAY be registered on one or more nodes to
+distribute the load of feasibility checks.
+
+To determine the feasibility of a job request, a ``feasibility.check``
+request is sent with the following REQUIRED key:
+
+jobspec
+   (object) The jobspec for which feasibility should be checked.
+
+If the included jobspec could not ever be satisfied, even if all resources
+were available and ready, then the ``feasibility.check`` service SHALL
+respond with a error response including a human readable error string.
+
+If the job could ever be satisfied, then success SHALL be indicated via
+a response with the following REQUIRED key:
+
+errnum
+   (integer) An integer error number zero (0).