I'm creating this issue to track down references. It does not need to be addressed before publication as a Candidate Recommendation.

For the Presentation API to be published as a final W3C Recommendation, normative references will need to reference stable specs, the rule of thumb being that a Recommendation should normatively link to other Recommendations (or similar documents published by other organizations) and not to working drafts.

There may be exceptions to the rule, which should be documented in the Status of This Document section. For instance, since WebIDL is not yet a Recommendation, recently published specs have sentences such as "By publishing this Recommendation, W3C expects the functionality specified in this Recommendation will not be affected by changes to Web IDL as the WebIDL specification proceeds to Recommendation." as in the Web Storage spec:
http://www.w3.org/TR/2016/REC-webstorage-20160419/#status-of-this-document

Also, we need to ensure that references are correctly flagged as normative or informative, depending on how they get used in the spec.

Making a quick pass through the spec:

• Check terms:
  • "in parallel", defined in HTML5.1.
  • WebIDL terms, although WebIDL Level 1 might move forward on the Rec track in the meantime
  • NotAllowedError, defined in WebIDL (Second Level) but not in WebIDL Level 1
  • Blob, defined in the File API spec
  • Terms defined in the Mixed Content spec
  • Terms defined in the Permissions spec
• Convert to normative references (because of their use in the "create a receiving browsing context" algorithm):
  • Cookies
  • IndexedDB
  • Permissions
  • WebStorage
• Consider updating the "create a receiving browsing context" to use prose such as "If the user agent supports IndexedDB, set the databases for C to an empty set of databases" to clarify that the action is conditional to the user agent supporting the feature in the first place.
• Consider converting references to HTML 5.1 (Issue #396)

I believe the Presentation API now references stable published specifications whenever possible.

One remaining open question: can the Presentation API simply reference the latest version of WebIDL, even though it is not in a stable state, or should the Presentation API spec continue to reference both WebIDL Level 1 and WebIDL Level 2 to point out all WebIDL terms used in the spec are defined in Level 1 except NotAllowedError which is defined in WebIDL Level 2?

I'll try to come up with an answer (needed before requesting transition to Proposed Recommendation, not needed for publication as Candidate Recommendation).

Can this be closed now @tidoust? All of the sub-tasks have been addressed.

Closing this issue since all updates were made to the spec, see follow-up issue #408 on reference to WebIDL.