Re: negotiated protocol in Navigation and Resource Timing

Such bikeshed, much wow... :)

Anne: thinking about this some more, it seems like "protocol" in Fetch has
it backwards. Historically, yes, you could just look at the scheme and
infer the protocol (http or https), but that is no longer the case because
https --> {http/1.1, http/2, spdy/..,  quic/..., ...}. If anything, I'd
argue we should drop "protocol" (we still have "scheme") from URL because
you don't actually know the protocol until the connection is negotiated. In
other words, moving forward URL.protocol will be lying most of the time.

With above in mind, I'd argue that we should stick with "protocol" in
NavTiming - it's the right term - and tell developers to use Nav+Resource
Timing to get at the real values, which are negotiated as part of
connection establishment, instead of simply relying on URL scheme.

----

I've put together a spec update @
https://github.com/w3c/navigation-timing/pull/4 - thoughts, comments?

If above looks reasonable I'll make a similar update for Resource Timing.

ig



On Tue, Oct 21, 2014 at 12:42 AM, Mark Nottingham <mnot@mnot.net> wrote:

> *shrug* sure.
>
>
> > On 21 Oct 2014, at 6:14 pm, Anne van Kesteren <annevk@annevk.nl> wrote:
> >
> > On Tue, Oct 21, 2014 at 3:14 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >> How about "protocolID"?
> >
> > networkProtocol?
> >
> >
> > --
> > https://annevankesteren.nl/
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>