- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 21 Oct 2014 12:14:44 +1100
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "William Chan (ιζΊζ)" <willchan@chromium.org>, Peter Lepeska <bizzbyster@gmail.com>, Tobin Titus <tobint@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, public-web-perf <public-web-perf@w3.org>, Tony Gentilcore <tonyg@chromium.org>
Well, this is like resource / representation; many developers don't need a lot of precision when choosing a term, but if they choose the wrong one, it makes things messy.
Most people working at this level understand that there can be a difference between "scheme" and "protocol." I don't know if introducing "transport" is helpful, since that literally means "TCP or UDP?".
How about "protocolID"?
> On 21 Oct 2014, at 4:37 am, Ilya Grigorik <igrigorik@google.com> wrote:
>
>
> On Mon, Oct 20, 2014 at 10:20 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Oct 20, 2014 at 7:15 PM, Ilya Grigorik <igrigorik@google.com> wrote:
> > Ah, I always assumed we'd expose both, but you're right, the functionality
> > we've discussed previously is all on Request... Hmm, will have to noodle on
> > this one some more. In the meantime, this is a good argument for why
> > "protocol" + {transfer, decoded}Sizes should, in fact, be exposed via NT/RT.
>
> Note that given https://url.spec.whatwg.org/#api the term "protocol"
> is unfortunately somewhat intertwined with "scheme" for many web
> developers. If we could expose it as "transport" or some such I think
> that would be clearer.
>
> Good point.
>
> All: any objections to s/protocol/transport/ ?
>
> ig
>
>
--
Mark Nottingham https://www.mnot.net/
Received on Tuesday, 21 October 2014 01:15:20 UTC