Consider refactoring navigation-timing to extend resource-timing

[toddreifsteck]

Much of the navigation-timing spec is the same as resource-timing. To avoid issues of copy/paste, perhaps we can define resource section in resource-timing spec and extend?

[igrigorik]

We have attributes that were surfaced in one but not the other (e.g. linkNegotiation{Start,End}), and others use out of sync language, etc... big +1 to this!

As we discussed on the call today, it seems like we can build NT on top of RT?

/cc @plehegar

[plehegar]

How would the prototype chain look like? We have 2 choices imho.

1. we simply add NT attributes into the RT interface:
   partial interface PerformanceResourceTiming {}
2. we extend the interface and define the NT attributes there:
   interface PerformanceNavigationTiming : PerformanceResourceTiming {}

I believe option 2 is the least disruptive.

[igrigorik]

NT is a superset of RT.. +1 to option 2.

[toddreifsteck]

+1 to option 2. Also, "algorithm" piece of the spec that refers to these fields should probably also be a pointer to a section within resource-timings spec as well.

[plehegar]

A lot of the attributes in RT have the following text:
[[
If the last non-redirected fetch of the resource is not the same origin as the current document, secureConnectionStart/responseStart/requestStart MUST return zero unless the timing allow check algorithm passes.
]]

However, NT doesn't have the text. I presume this is intended and will have to be taken into account, correct? Ie the the document being navigated to isn't from the same origin, you still return a proper value (and not zero).

[plehegar]

RT has initiatorType but NT doesn't. How about, in the case of NT, we return "navigation" for initiatorType (same as entryType)?

[plehegar]

Reassigning this one to me so that I get around it.

[plehegar]

See #36

[igrigorik]

Resolved via #36, closing.