Re: ACTION-446: Conformance model

> again, I'd like those who are explicitly addressed by this message
> to specifically review the proposed changes.  Note that this is also

You had names on both the to: and cc:. Can you name names so we can all be 
clear about who you mean? 


It's all quite good. 


> The "For example" list of things that we had put into section 4
> (interaction and content model) at the face-to-face is a bit of a
> problem. It kind of talks about conformance for plugins, but is
> really just an example.  As such, it doesn't fit into section 4.
> 
> In the conformance section (where I've tentatively put it), I'm
> worried that this text is going to be a major source of confusion,
> as it appears to enumerate a specific list of features that are
> important for plugins, but actually doesn't (since it's just an
> example).  I'd therefore propose to strike this text; I suspect that
> Mez, Joe and others will have opinions about that.

Can it move to the security considerations section? Here's a stab at how 
that would look: 

Plugins wishing to claim conformance will need to understand the 
implications of all of the clauses of the conformance level they wish to 
claim. For example, plugins which call TLS or present TLS secured content 
will need to conform to requirements in 5 Applying TLS to the Web, or 
ensure they defer handling of those requirements to some other portion of 
the user agent. Plugins will need to neither obscure nor degrade the 
rendering of user interface components described in 6.1 Identity and Trust 
Anchor Signalling, 6.2 Additional Security Context Information, and 6.4 
Error handling and signalling. In addition, a plugin will need to conform 
to 6.4 Error handling and signalling for all security related errors it 
handles. Plugins will need to conform to the 7 Robustness recommendations, 
with particular attention to 7.1.2 Keep Security Chrome Visible, 7.4.4 
Pop-up Window APIs, and 7.4 APIs Exposed To Web Content.