Re: negotiated protocol in Navigation and Resource Timing

After a few iterations (thanks Mark!), we've arrived at:

------- (discussion @ https://github.com/w3c/navigation-timing/issues/2)
------

readonly attribute DOMString protocol;

This attribute must return protocol used to fetch the resource, as
identified by the ALPN Protocol ID (see https://tools.ietf.org/html/rfc7301).
When a proxy is configured, if a tunnel connection is established then this
attribute must return the ALPN Protocol ID of the tunneled protocol,
otherwise it must return the ALPN Protocol ID of the first hop to the proxy.

In order to have precisely one way to represent any ALPN protocol ID, the
following additional constraints apply: octets in the ALPN protocol must
not be percent-encoded if they are valid token characters except "%", and
when using percent-encoding, uppercase hex digits must be used.

Note that this attribute is intended to identify the protocol in use for
the fetch regardless of how it was actually negotiated; that is, even if
ALPN is not used to negotiate the protocol, this attribute still uses the
ALPN Protocol ID's to indicate the protocol in use.

----------

Above would apply to Navigation Timing and Resource Timing - aka, you can
get the protocol for each resource fetch.

*Tobin:* could you run this by the IE networking team for feedback?
*Patrick: *any feedback from Mozilla side?

ig

On Tue, Oct 14, 2014 at 7:47 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> On Tue, Oct 14, 2014 at 3:26 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> Gave my feedback on the issue. I think you misunderstand -- ALPN isn't
>> required to be used to use its protocol identifiers as a name space. That's
>> what a lot of protocols are currently doing (e.g., RTC, TURN).
>
>
> Doh, you're right, misread your original proposal. Thanks for the
> clarification!
>
> How about this:
> https://github.com/w3c/navigation-timing/issues/2#issuecomment-59150636 -
> getting closer?
>
> ig
>
>