W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > July 2012

Minutes from 3/7/2012 Coordination Call

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 6 Jul 2012 08:54:33 +1000
Message-Id: <BFBD2017-3923-4C3F-8D27-04B4F53230F9@mnot.net>
To: public-ietf-w3c <public-ietf-w3c@w3.org>
W3C/IETF Coordination Call
July 3, 2012

14:00 PT / 17:00 ET / 23:00 CET

John Klensin (JCK)
Philippe Le Hégaret (PLH)
Mark Nottingham (MNOT)
Peter Saint-Andre (PSA)
Thomas Roessler (TLR)
Barry Leiba (BL)
Robert Sparks (RJS)
Julian Reschke (JR)
Sean Turner (ST)
Alexey Melnikov (AM)

Stephen Farrell (SF)
Gonzalo Camarillo (GC)

1. HTML5 + URI schemes, and http+aes
- web+ scheme prefix
- http+aes @ WHATWG

PLH: web+ is part of HTML5; http+aes is WHAT-WG
PLH: There is an open issue on web+
PLH: Chairs are almost ready to survey the group on proposals
PLH: One of them is that a prefix doesn't constrain IANA registrations
PLH: Talked to the IRI WG; they said it was out of scope
PSA: That was one person's opinion; that wasn't a WG perspective
PSA: At the last IETF meeting, we said it doesn't belong in the registration procedure bis effort
PSA: It would be helpful for someone to write up an I-D or more formal proposal
PSA: The text in the HTML5 spec isn't clear (as co-chair of the IRI WG) what the import of 
... the text in the HTML5 spec is. E.g., what should IANA do? Reviewers?
PSA: If people think this is a good idea, they need to have some formal rules about how
... it works.
PLH: As I understand it, the current spec is misleading, because it looks like a registration
... form, when it shouldn't be. It's more of a guideline for URI scheme authors, or a 
... template. So I'm not sure if an RFC would be useful.
PSA: I thought that the guidelines there would be pretty weak. Can you do whatever you want with a web+ scheme?
PSA: You're also reserving a special prefix; this doesn't seem like a great idea.
PLH: As I understand it, it doesn't have any specific additional rules.
PLH: We'll need to get the right people together for further discussion.
AM: Are there any examples?
PLH: The HTML5 spec does define some.
TLR: How would this go through CR? Are people actually going to use it? Or is this just
... another trial balloon.
PLH: It could disappear during CR.
TLR: If nobody actually wants to use it, it may not be worth bothering.
PLH: Or wait until one is actually registered.
MNOT: I can't escape the feeling that this is like the IETF defining a prefix for HTML tags.
MNOT: If this is just a trial balloon, we should definitely wait.
JR: I pasted in a link for test cases; http://web.lookout.net/2012/01/testing-registerprotocolhandler-and-web.html
JR: It was implemented in Chrome and Firefox
PSA: If you look at the definition of the protocol handler, any scheme defined with web+ gets a pass as far as security is concerned. This doesn't seem like such a great idea for security.
JR: For people inventing new protocols, there's a reason to prefix everything with web+.
MNOT: We've had similar experiments in the past. The rationale seemed to be avoiding the need to upgrade browsers. Is this still needed given that browsers are updated more frequently now? It doesn't seem to be a good idea to put metadata into identifiers.
TLR: Agenda interrupt
MNOT: Will someone from W3C be at IETF 84 in Vancouver?
TLR: Someone will be there, yet to be determined.
PLH: As to http+aes, it was removed from the HTML spec and is now at WHATWG. Still a few participants interested in it, but interest is minimal at this time in the HTML WG.

2. Media fragments working group
- progressing to REC
- not asserting authority over media type registrations
- normative reference from HTML5 & CSS3 Images

PLH: Document provides guidelines for media objects (audio, video, etc.) to incorporate temporal and spatial components. Two references to that work (HTML and CSS3) as one topic to consider when defining relevant media types. Questions? [none]

3. hybi / websockets
- status update

BL: Work in the IETF continues
PLH: Are colocating with webrtc; not much to worry about

(plh later realized he was confused about this point; see WebRTC)

4. IRI / URI:
- URL Working Draft published at W3C:
- IETF IRI WG progress?

PLH: Working Draft published in May regarding how to get a string into a URL
PSA: Right; we decided that at TPAC
MNOT: Part of a WG?
PLH: Yes, WebApps
JR: It doesn't tell us what problem it wants to solve; it starts with the premise that there's
... something wrong with the URI spec, but doesn't explain what it is. A statement as to
... how it's different from the URI spec, or how it relates to it, would be helpful. I've made
... this comment many times. (The parts about handling *illegal* URIs, and defining a JS 
... API are understood)
JCK: You have had some responses, in a way, regarding where URIs are going.
PLH: Progress of the IRI WG itself?
PSA: Continuing to work through open issues (slowly). Larger issues (such as what John 
... mentioned) would be good to clarify. There are now several documents. Does the W3C
... have concerns about how to procede here?
PLH: Not that I'm aware of.
JCK: The draft which I've talked about regarding i18n - I hope to give you a preview before 
... the end of the week. It argues that the existing IRI spec should be considered a failed
... experiment and obsoleted.
PSA: I look forward to that discussion and the resulting decisions. If that's the path we go
... down, there would be implications (e.g., to XML Schema).
TLR: No direct concern about the progress of the WG, but we do have multiple dependencies.
PSA: I18N is always messy.
JCK: This has been a mess for at least two years and probably much longer.
PLH: Is Addison still active in the IRI WG?
PSA: Not that I have seen.
[ note: see also item 9 WRT IRI WG ]

5. WebRTC
- future of media capture API
- identity abstraction
- rtcweb progress @ IETF?
- https://datatracker.ietf.org/doc/draft-aboba-rtcweb-ecrit/

PLH: Sorry about missing the feedback.
PLH: We recently published the media capture and stream API; used to be part of WebRTC.
TLR: WebRTC needs an abstraction for identity; EKR has a draft. Discussion ongoing about
... where and how to standardise; current thought is W3C. 
RJS: Some discussion in the IETF, but nothing concrete.

- httpbis
- http 2.0

MNOT: As to 1.1, we have finished WGLC for parts 4 through 7, edits being completed. Parts 1 and 2 are also in progress. New drafts in a week or so. That will get us down to one or two substantial issues. Still need more editorial work on 1 and 2, Roy needs some time to work on that. Hopefully WGLC soon before or after IETF 84, IETF Last Call soon after then. Still need to determine if we need a Part Zero to act as an introduction and a single spec to refernece.
MNOT: As to HTTP 2.0, we have three proposals for wire protocols and a number of proposals for authentication schemes. Right now asking for expressions of interest in implementing those proposals. Will have discussion in Vancouver about which proposal is most appropriate for the protocol, and gauging interest in an authentication scheme.
BL: When do you think we'd have the set of 7 HTTP 1.1 documents to the IESG?
MNOT: Actual amount of feedback we received was relatively contained, Part 1 was a bit more expansive. We're giving Roy time to incorporate edits, but not an infinite amount of time. Should be sent to IESG in the September timeframe.
BL: About authentication mechanisms, do you think it's likely that we'll get a critical mass behind any particular mechanism?
MNOT: I'm looking for something that the browser folks can get behind, or something that doesn't require coordination with browser developers.

7. websec / webappsec
- progress updates

TLR: CORS is in Last Call, CSP is in Last Call, framing options and other work is less clear.
BL: Progressing on what work it's doing about smaller issues, but the large framework is receiving less attention.
AM: HSTS is just about to be submitted for AD review, and frame options is making progress.
TLR: Is this frame-options or x-frame-options?
PSA: Both.

8. W3C plans for Testing Workshop

PLH: Very early notice; we're looking to organise a testing workshop to focus on testing the Web platform, as related to the television industry. Don't have a timeframe yet; perhaps
late (Northern) fall in the U.S.

9. W3C I18n WG rechartering

PLH: Chartering to work on draft specification above.
PSA: Didn't seem to me that normalization was getting a lot of attention. Did I miss anything?
PLH: No; it's a touchy subject. This is about character encoding; how to interpret
... the received character encoding.
JCK: As soon as you get to sub-comparison, you get to the normalisation problem.
TLR: Is there any expected fallout from the IRI work that this work will need to deal with?
JCK: Short answer, yes; IRIs and precis. Do you want to appoint me as an external expert,
... or sit on the IETF side and throw rocks?
PLH: I'll get back to you.
TLR: Do we have a good enough idea that the shape that the IRI work is going to take? E.g.,
... additional work? When it might be needed? When should we discuss?
JCK: I'll defer to Peter, but I think the WG is at a junction once again, where it needs to
... make decisions. This hypothetical draft is completely disruptive; we're at a fork in the
... road. Third option is to give up, which has been seriously discussed.
TLR: Please loop us in; this decision has many implications for our architecture.

10. precis & TC 39 JS Unicode work

PLH: Wanted to make sure the IETF was aware of this work.

12. JSON Pointer / JSON Patch

MNOT: Wanted to make sure the W3C is aware of work at the APPS AREA WG on JSON pointer and JSON patch. 
AM: APPSAWG chairs are grateful to Mark for the help!

13. WebFinger

MNOT: Again, want to make sure that W3C is aware that APPSAWG is taking on work about WebFinger. Currently uses host-meta and XRD/JRD. That may be of interest to W3C since it is similar to some W3C (and IETF) technologies.
TLR: Does that depend on XRIs as well, or only XRD?
PSA: Only XRD.
BL: The impetus for this work came from the OAUTH WG and their work on Simple Web Discovery (which itself came out of the OpenID), and a desire to harmonize the two approaches so that we didn't have two solutions to the same problem.

14. W3C TAG comments during IETF Last Call

Discussion postponed.

15. 3023bis now in Applications Area Working Group

PLH: Work on 3023bis is moving to APPSAWG.
AM (typed): Or it is supposed to be, but I am no longer a co-chair so can't control this ;-)
But where is the draft???

Who is going to edit 3032bis in IETF?

16. Vancouver IETF
- hot topics?
- who's going? Who should go?

TLR: Anything not on this agenda that's likely to require coordination?
ST: ITU web mashup liaison?
TLR: I've drafted ours, still haven't sent.
ST: Will talk to Eliot, coordinate.
PLH: It sounds like both TLR and I need to be in Vancouver.

ACTION: MNOT to organise post-Vancouver meeting.

Mark Nottingham   http://www.mnot.net/
Received on Thursday, 5 July 2012 22:55:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:35 UTC