manifest feedback

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

LH: The UA should handle idna for us.  I think this is a noop.

IB: Hmm... yeah, now that I think about it.  It could be a little assert sometime if we want,
just to make sure the UA is not weird.  We don't care about non-ASCII anywhere but the
origin, and the origin isn't in the manifest, so we're okay.

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.

LH: done: http://bit.ly/egj8zU

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?)

LH: done: http://bit.ly/hHvdmo

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

LH: yay!

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

LH: unsure what to do.  we could explicitly disable it, throw an error...  thoughts?

IB: it would be nice if urlmatch functions had an option to disallow that form, or... maybe
some other flag to disallow it.  It's not really part of the http(s):// specification, just
a convention that some browser started implementing.

"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.

LH: yeah, I don't know what we should do about capabilities.  it's a discussion
we should start on list, shouldn't block merge tho.

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

LH: hmm

IB: here's the spec on icons: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-icon

IB: notably it allows space-separated sizes, which means keying on size wouldn't really work.  Sizes are two-dimensional, and include the keyword "any" (e.g., for SVG).  They also include "type" (which seems more traditional for <link> than useful) and "media" (which could be useful?).  At least the addition of the "any" size seems useful.

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).

LH: name?  512?  desc?  4k?

IB: those are on the long side, but we can say that UA's can truncate anything after some shorter length, at their discretion.  Err... some of those other specs that mhanson has referred to have specific lengths they suggest, which are quite a bit shorter.

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.)

LH in code, it's actually a whitelist right now.  search for may_overlay in manifest.js

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

LH: totally and completely opaque to the repository.  an unfortunate implementation
detail to mitigate problems caused by manifest updates requiring prompting.  this may
change depending on the fates of capabilities.

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

LH: I don't mind adding language, you don't think 'origin' is widely understood? 
http://en.wikipedia.org/wiki/Same_origin_policy

IB: I did not originally realize it included the scheme.

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?

LH: No.  That sentence is a vestige.  Do we even need to mention that
app devs may serve their files using standard headers in the appropriate way?
I don't think its necc.

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.

LH: I'm fine with allowing unknown keys.  let's start a small discussion 
on list?  I can start it.

default_locale could be optional if the "locales" key is not in the manifest.  In that case there's no localization possible anyway, so the "best" locale is always the "only" locale, be it "en" or "es" or whatever.

LH: I like this change too.