Beginning to realize that the main thing out of a file header in a diff that matters is the identification of the target resource--the one whose line begins with "---". Almost everything else is optional for processing a diff later, or is interesting for human consumption at a different point in time (e.g. to eyeball that the patch was generated as 'diff old new' and not 'diff new old'). Also almost every tool I've found generates something different in the 'file header' portion, yet patch seems to be able to handle them all, I suspect because it largely ignores everything beyond trying to figure out if the target file (---) exists relative to its current context (current directory less -p level).
Incorporated the URI grammar by reference. Regular filenames and paths match the "relative-part" production of RFC 3986, but generalizing this to particular resources allows for more general use. #10
The first use is to compare two versions of a single file, and the second use is to compare the contents of two distinct files.
This means not all output of the diff command will be a valid text/diff file, in particular, the "I converted the README from ISO-8859-1 to UTF-8" diff won't be expressible this way, as it will have a mixture of those two character sets and hence won't be a valid text/* file. Previous discussions on the ietf-types list opined that two media types could be registered, text/diff (where the patch is itself a valid text file) and application/diff for everything else. I've adopted this stance in the current proposal and limited the scope accordingly.