Re: [Navigation Timing] Feedback on the working draft

  Thanks, Anderson. Pls find comments inline.

On Mon, Nov 29, 2010 at 6:32 PM, Anderson Quach <aquach@microsoft.com>wrote:

> Section 1.0 Introduction
>
> ·         typo s/the time it take to/the time it takes to/
>
>
>

    fixed.



> Section 4.2 The PerformanceTiming interface
>
> unloadEventStart –
>
> ·         correction s/starts unloading<http://dev.w3.org/html5/spec/history.html#unloading-documents>the previous document/starts the unload event of the previous document/
>
>
>
> unloadEventEnd –
>
> ·         correction s/finishes unloading<http://dev.w3.org/html5/spec/history.html#unload-a-document>the previous document/finishes the unload event of the previous document/
>
>
>

     now I have some doubts about this. Do we only want to time the unload
event? Or, do we want to time the
entire unloading
process<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#unloading-documents>,
which includes the unload event? The latter is more reasonable since I am
not sure
why we'd be particular interested in the unload handlers from the previous
page.



> redirectStart –
>
> ·         typo, s/intiates/initiates/
>

   fixed.


> ·         correction s/the redirect and the document at the end of the
> redirect are from the same origin<http://dev.w3.org/html5/spec/origin-0.html#origin>/all
> the redirects or equivalent must come from the same origin/
>

   fixed.


> ·         removal, this text is confusing. If there is a redirectStart,
> this is captured immediately after navigationStart.  This nuance is better
> described in the processing model. – ‘redirectStart is the equivalent of the
> fetchStart attribute of the navigation that initiates the redirect.’
>

    fixed.


>
>
> redirectCount –
>
> ·         addition ‘This attribute must be zero if there are any non-same
> origin redirects.’
>

    fixed with some minor change according to the existing text.


>
>
> redirectEnd –
>
> ·         removal, if there are different origins in the redirect chain
> then the redirectStart, redirectEnd and redirectCount must be zero. ‘The
> relaxed same orgin policy doesn't provide sufficient protection against
> unauthorized visits across documents. In shared hosting, an untrusted third
> party is able to host an HTTP server at the same IP address but on a
> different port.’
>
    If the description in this note is accurate, I think we can keep it for
reference. It's not normative.



>
>
> domainLookupEnd –
>
> ·         typo s/immmediately/immediately/
>

    fixed.


>
>
> connectEnd
>
> ·         To prevent undefined gaps in the timeline, it’s recommended that
> the connectEnd time to be inclusive of SSL handshake and SOCKS
> authentication. The recommended text goes as follows: s/It must not include
> other time interval such as SSL handshake and SOCKS authentication/It can
> include other time interval such as SSL handshake and SOCKS authentication/
>
    This seems to be under discussion so I will hold on to it.



>
>
> loadEventStart
>
> ·         typo s/the the/the/
>
     fixed.



>
>
> Section 4.3 The PerformanceNavigation Interface
>
> type –
>
> ·         typo s/url/URL/
>

    fixed.


>
>
> Section 4.5 Processing Model
>
> typo s/This secion/This section/
>

   fixed.


>
>
> It should be sufficient to have one image that describes the Navigation
> timing timeline and express that the unload event can be on an independent
> timeline.
>

    sounds good. I keep the redirect chart only.


>
>
> Step 13
>
> ·         Question: The wording of the comment in this step implies that
> the connection is then re-opened. Would you want it to state, the following
> instead: s/Return to step 11/Return to step 10/
>

    Good catch. Yes, should be step 10.


> ·         Removal, this appears to be redundant as it’s already covered in
> the processing model for initialization values of connectStart, connectEnd
> and requestStart. “When persistent connection [RFC 2616] is enabled, a user
> agent may first try to re-use an open connect to send the request while the
> connection can be asynchronously closed. In such case, connectStart,
> connectEnd and requestStart should represent timing information collected
> over the re-open connection.”
>
     It's redundant since it's an example for step 10 - 13. :-)

cheers,
Zhiheng



>
>
>
> ------------------------------
>