gistfile1.txt

The origin should be an ASCII URL, that is, non-ASCII characters
should be normalized down to ASCII.

We are relying on urlmatch.js's normalization of :80 etc, not testing
that directly (because it makes the tests hard to run).  We should
verify that all URLs are being normalized in all code paths.

Widgets are allowed in the code but not noted in the spec, need to be
readded.  Takes a path and a preferred size, like {"widget": {"path":
"/widget.html", "width": 100, "height": 100}}.  Height and width are
optional and are suggestions (the dashboard may not respect the
suggestion).  (List of preferred sizes?)

To actually construct a URL from a manifest you need the full
installation object, which contains the origin; the manifest itself
does not contain the origin.  They "key" is the origin

urlmatch.js allows for username:password@, but that doesn't have any
meaning or place in this specification.

"capabilities" are mentioned, but with no meaning.  Should we have
something in the spec that has no meaning?  It presupposes that it
will have a meaning, but since we havne't determined a meaning that
seems premature and like it's sneaking in a feature without clear
discussion.

Icons are not clearly specified.  Maybe we can take the specification
from <link rel="icon">?

There's no maximum or preferred length on name and description.  It's
not specified how it should be rendered; presumably all markup is
quoted (but e.g., <> is allowed) and whitespace is normalized (i.e.,
newlines become spaces).

Should locales have a whitelist of things that are allowed to be
overridden?  Now it's a rough blacklist.  IMHO only human-readable
things should be replaceable (possibly including the icons, which are
readable in a sense).  Origin was originally kind of allowed for, but
does not seem valid any more.  (This means, e.g., you must install the
English Wikipedia or the Spanish Wikipedia, you can't select language
after installation -- but that represents a real institutional divide
in Wikipedia anyway.)

version: Presumably it's not even sortable in any sense?  Also, not
user visible?

We should probably point out that origin includes http/https and port.

I'm not sure what if anything Last-Modified on the manifest will
accomplish or do?  Is that value stored in the installed record?  Does
it provide a default for version if it is not otherwise specified?

We don't say how unknown keys are handled.  I think they should be
ignored in all positions (e.g., manifest.developer.email should be
okay, just ignored).  Also not just validation, but if they are
preserved when stored in the repo.  This also implies that the
presence of any value cannot mean user confirmation, as a user agent
that didn't understand the key may have installed the app.
Confirmation should be stored separately, as a positive assertion.
The presence of any value (outside origin which we have encoded in
version 0, essentially) does not mean the user was fully notified and
consented to that value.