Re: [art] Reminder: WHATWG Bar BoF

[=JeffH <[e-mail]>]

On Sat, Mar 17, 2018 at 1:12 PM Mark Nottingham <[e-mail]> wrote:
 > .... is tomorrow (Sunday) at 7pm, in the IAB room (Hilton Meeting
 > Rooms 5-6, on the Tower Wing 3rd Floor).

did anyone take notes of yesterday evening's discussion that are more 
detailed (eg who's doing what...) than what I've got here...

Maciej noted that there's (at least) 4 WHATWG specs of interest to IETF:

   https://encoding.spec.whatwg.org/
   https://fetch.spec.whatwg.org/
   https://mimesniff.spec.whatwg.org/
   https://url.spec.whatwg.org/

we discussed encoding & Mime-sniff, mostly figured out paths fwd on them 
(who? what?).

wrt Fetch, I will reveiw and comment on @vanupam's TokBind PR.
also, IIRC, there was some discussion of Fetch perhaps being factored 
into what is useful to HTTP-speakers in general, and what is browser 
specific...

RFC6454 Web Origin Concept was mentioned in passing and some wondered 
whether it is another candidate for "harmonizing"... [1]

no one seemed to want to discuss the URL tar-baby... [1]

HtH,

=JeffH

[1]
From: apps-discuss <[e-mail]> on behalf of =JeffH 
<[e-mail]>
Date: Monday, July 18, 2016 at 4:28 PM
To: "[e-mail]" <[e-mail]>
Subject: [apps-discuss] RFC6454 "the web origin concept" obsoleted?

[This is more-or-less a heads-up public service announcement/query wrt
process...]

In the below relatively recent exchange on the HTTP WG's list 
ietf-http-wg@..

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0323.html
On 3/3/16, 3:10 AM, "Anne van Kesteren" <[e-mail]> wrote:
 > On Mon, Feb 22, 2016 at 1:45 PM, Mike West <[e-mail]> wrote:
 >
 >> I think we need precision somewhere. I'm fairly agnostic about where
 >> that somewhere might be. Adding Anne, who might be interested in
 >> defining terms like these in Fetch?
 >
 > Seems fine. (Though note that the Origin RFC comparison does not quite
 > fly, it's made obsolete by the combination of HTML, Fetch, and URL
 > Standards.)

..Anne notes that (in the WhatWG's (and others?) view), RFC6454 "The
Web Origin Concept" is obsoleted by the combination of (the present,
and intended on-going state of) [HTML], [FETCH], and [URL].

This seems to beg some questions for the HTTP WG and the IETF at large
(and perhaps the WhatWG, as well as the W3C), since [HTML] and [FETCH]
are implemented by browsers and browser-like HTTP clients (e.g.,
crawlers/spiders), but not necessarily other types of HTTP clients,
[URL] is intended (by its author(s)) to obsolete RFC3986 & RFC3987
[URLgoals], and RFC6454 is referenced by nine RFCs [0] and several
I-Ds [1]:

* Should some I-D appear that is intended to obsolete RFC6454 and
points to [HTML], [FETCH], and [URL] as the present specs addressing
the Web Origin Concept?

* Or should some I-D appear stating that for browsers and browser-like
HTTP clients, see [HTML][FETCH][URL] for the Web Origin Concept, and
for other HTTP clients, see RFC6454?

* Plus, should the change(s) to the functionality & definitions in
RFC6454 be back-ported to a rfc6454bis ?

* Are the changes to RFC3986 & RFC3987 evidenced in [URL] widely
applicable to all URL-utilizing specs and if so, do we obsolete them
and point to [URL], or backport the changes to RFC3986bis &
RFC3987bis? Or do something else, or do nothing?

The above questions and the issues they beg are just off the top of my
head, need refinement, etc.

Perhaps the duplication between "orgs" doesn't matter and everyone can
figure out what specs to pay attention to given their context? I don't
know the answers but thought I'd toss out the questions...

HTH,

=JeffH

ps: note also that [HTML] and [FETCH] are referenced by
draft-ietf-httpbis-cookie-same-site:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0432.html


[FETCH] https://fetch.spec.whatwg.org/

[HTML] https://html.spec.whatwg.org/

[URL] https://url.spec.whatwg.org/

[URLgoals] https://url.spec.whatwg.org/#goals

[0] RFC6454 is ref'd By 6555, 6690, 6787, 6797, 6920, 7030, 7034, 7395, 7486

[1]  (some of the below may be expired, I didn't check)
grep -li rfc6454 *txt
draft-dejong-remotestorage-07.txt
draft-ietf-appsawg-file-scheme-11.txt
draft-ietf-core-coap-tcp-tls-03.txt
draft-ietf-httpauth-mutual-08.txt
draft-ietf-httpbis-alt-svc-14.txt
draft-ietf-httpbis-cache-digest-00.txt
draft-ietf-httpbis-cookie-same-site-00.txt
draft-ietf-httpbis-http2-encryption-06.txt
draft-ietf-httpbis-origin-frame-00.txt
draft-ietf-rtcweb-security-08.txt
draft-ietf-rtcweb-security-arch-12.txt
draft-ietf-tram-stun-origin-06.txt
draft-ietf-webpush-protocol-07.txt
draft-ietf-webpush-vapid-01.txt
draft-kazuho-h2-cache-digest-01.txt
draft-nottingham-httpbis-origin-frame-01.txt
draft-pd-dispatch-msrp-websocket-12.txt
draft-reschke-http-oob-encoding-07.txt
draft-savolainen-core-coap-websockets-07.txt
draft-sheffer-tls-pinning-ticket-02.txt
draft-thomson-http-scd-01.txt
draft-thomson-webpush-vapid-02.txt


From: apps-discuss <[e-mail]> on behalf of John C 
Klensin <[e-mail]>
Date: Monday, July 18, 2016 at 11:04 PM
To: Daniel Stenberg <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [apps-discuss] RFC6454 "the web origin concept" obsoleted?

Hi.

One, possibly-useful addition to what Daniel has written below.
According to RFC 3986, but completely ignored or rejected by the
WHATWG URL spec, one of the reasons the terminology was switched
to focus on the term "URI" is that there are URIs that are not
URLs or even "locators" but "names".  In retrospect, that switch
might have been a mistake but it affects today's reality.  In
particular, the most important name-type URIs are URNs (or,
because there is even more confusion, more precisely URIs of
scheme "urn:").  URNs of that variety (specified by RFC 2141)
never use "://", a typical one might look like
"urn:ietf:rfc:3986" or "urn:issn:2070-1721".

Independent of the [URL] document, many people have argued
strongly that, for example, the piece of HTML that allows URLs
in <a> elements is required to accept [generalized] URIs (not
just HTTP and HTTPS URLs) and process them in some way, making
the above distinctions either important or troublesome,
depending on how one looks at the issue.  "Argued strongly" is
not intended as any disrespect -- it is hard to read the HTML
specs in any other way.

The URNBIS WG is in the process of updating RFC 2141 and some
related specs to allow more capabilities and to better reflect
contemporary practice and requirements.  I'd recommend its
mailing list, discussions, and documents to anyone interested in
seeing another direction for where these discussions lead.

best,
     john


 > On Monday, July 18, 2016 23:00 +0200 Daniel Stenberg
 > <[e-mail]> wrote:
 >
 > On Mon, 18 Jul 2016, [e-mail] wrote:
 >
 > * Are the changes to RFC3986 & RFC3987 evidenced in [URL]
 >> widely applicable  to all URL-utilizing specs and if so, do
 >> we obsolete them and point to  [URL], or backport the changes
 >> to RFC3986bis & RFC3987bis? Or do something  else, or do
 >> nothing?
 >
 > The [URL] spec is mostly followed by browsers while the rest
 > of the URL parsing world is all over the place but very few
 > non-browsers implement the [URL] spec and instead do various
 > mixes of what the RFCs say and the browsers do. I blogged
 > about this exact issue a short while ago [1] after having
 > realized the [URL] spec says eight thousand slashes in a HTTP
 > URL is fine and should be parsed.
 >
 > I personally am not a fan of neither the [URL] spec style (I
 > find it very hard to read), how it is being written or what it
 > says a URL can look like. But I know I get a lot of objections
 > and "web compatibility" arguments thrown at me when I say so...
 > So the RFCs are currently lacking a lot when it comes to
 > parsing modern URLs, but the [URL] spec is not even trying to
 > make a spec for an entire web infrastructure so it isn't a
 > generic solution either. I don't have a good answer for where
 > we should go from here.
 >
 > [1]
 > https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/



---
end