See also: IRC log
<trackbot> Date: 04 November 2010
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
[intros and description of TAG's purpose]
Thomas: I am here representing W3C-IETF liaison.
Noah: [pointing out point 3 in
mission statement - help coordinate cross-technology
architecture developments inside and outside of W3C.
... Topics?
<lmm> topics: process: coordinating with IETF
<lmm> specific documents: mime-web-info
<lmm> specific documents: iri
<lmm> more generally: how to coordinate better with IAB, IESG, getting TAG review of IETF things that affect web architecture
<lmm> topics: web security & privacy
<lmm> tag as member of apps area review board?
<lmm> http://tools.ietf.org/html/draft-masinter-mime-web-info
<noah> http://tools.ietf.org/id/draft-masinter-mime-web-info-01.html
Noah: Started writing this document... Is this an IETF document? [where should it go?]
Tim: Could it be an Internet draft?
Noah: A TAG finding means the TAG is standing behind it?
Alexei: As an ID it can be
circulated in IETF.
... Purpose to describe issues and realign future work?
Larry: [describes document]
Noah: should you mention SIP?
Alexei: [touching on possible applicability to SIP]
Larry: This document is about
what is wrong with MIME on the Web - it's a set of
recommendations for changes.
... Covering what are the requirements for recommendations.
Thomas: looking at this document
- another document needs to appear - the web is not mime - it's
mime-like. There are things like transfer-encoding out of the
scope of mime.
... there is relatively concrete guidance needed about what
those differences are.
... I would love to see that documentation.
... these cost us time.
Larry: My goal is to fix things so that the Web can be a mime application.
Larry: this document could be an IETF requirements document - it also proposes changes to w3c documents.
Noah: We could publish it on our own track if we wish.
Larry: The TAG could publish an informational document on what we recommend the IETF should do.
Alexei: My concern is - what is the status of this document in IETF? Should this become an IETF consensus document?
Larry: it's intended to be informational.
Alexei: Ideally it should reflect consensus of both [ietf and w3c] communities.
<noah> Noah: at this point, from a TAG point of view, this is a draft that Larry has asked us to review. So far, the TAG has expressed no formal opinion, though informally it's clear that we feel the effort spent on this is very worthwhile.
Yves: Should it be a document sent for consideration to the IAB?
Alexei: [possibly...] IAB does publish documents in their stream...
Larry: I would like to push sooner rather than later. Could we ask for review now?
Noah: The TAG could take an
opinion on this and express it "to IETF" but this affects lots
of other people at W3C - [should we reach out to other working
groups and inform them of the current state]?
... Maybe the TAG should reach out to a broader W3C community -
e.g. the chairs list and www-tag.
<noah> DKA: Privacy workshop in December. There's an IAB mailing list where a joint IAB/W3C/IETF community has come together.
Noah: Seems like we should reach out within the w3c... Then we can decide whether to [e.g. create a mailing list].. Don't think it requires that right now.
Larry: having an IEFT co-editor would help?
Alexei: Yes.
... [agrees to look for someone in the mime community to help
with this]
Alexei: html wg comments - they
thought that some useful text was lost during transition.
... should be taken care of by reporting bugs on IETF
specs.
... also some issues of perception on IETF process...
[...discussion on current state of the specification...]
Tim: I was concerned with the last document we reviewed - an expectation that anyone who processes an IRI would be expected to code it up as punicode.
Alexei: I think that's one of the open issues.
Tim: There's a huge implication on software to be changed...
Larry: the previous RFC
recommended that - compared to the harm of sending a
percent-encoded hostname to a dns resolver - to a legacy,
unaware client.
... it was my impression that the implementations parse the
URI, got the hostname out as a unicode string, then punicode it
(not percent-encode it).
Noah: [paraphrases tim] when
these things are flying around they should be unicode or
percent encoded, not punicoded.
... if you want to work with old systems and you don't know
what they do, something wrong might happen...
Tim: At some point you have to put the punicode conversion in.
Larry: boundary is - I have a legacy system that only takes URIs - I want to give it something valid - percent-encoded hostnames won't work - only think that will work is punicode.
Thomas: observation: punicode is
something we're able to transmit over the wire with 100%
fidelity. We don't have that fidelity for everything that ever
may be treated as an IDN.
... there are mappings. These mappings [are problematic].
... e.g. greek sigma problem - difference between IDN
versions...
... robustness consideration that favors punicode as the thing
you put on the wire.
Tim: You should do the punicode encoding in one place in your system - near the DNS.
Thomas: No, closest to the authoring.
<DKA_> ScribeNick: DKA_
<tlr> at some point, there needs to be discussion of this draft: http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-02
<tlr> (could be next liaison call)
Noah: Break. Re-convene at 4:30.
<tlr> there is one architectural issue from the security piece that I'd like to at least put on the table with TAG, Tim and Alexey in the room. HTTP / HTTPS distinction.
Alexei: You [w3c] have multiple
types of working groups - creating new types of groups.
... Ideally it would be nice to let IETF know and IETF should
let you know about BoFs and working group proposals. What's the
best way to do this?
Tim: Where do we send it?
Alexei: There is a new work mailing list.
Larry: When new community groups get formed we could let IETF know.
Thomas: There's a dormant[?] new work mailing list [in ietf]
<tlr> I'll check in with DanielD on that.
Noah: this sounds like a general liaison issue.
Thomas: I know who I need to talk to on that.
<noah> Noah: In particular, I think Thomas as liaison should undertake to make sure IETF gets the notifications they need; not directly a TAG issue.
Larry: I wonder if there should be any workshops between TAG and IAB - higher level coordination that we should have.
Alexei: There is a coord call.
Larry: It tends to be tactical.
Alexei: Also process.
Thomas: My advice would be to find a separate channel for architectural discusssion.
Dan: Could we organize one joint conference call?
Alexei: Yes - ISG might also be
interested?
... Could you come up a list of things you want to talk
about.
Thomas: [Some IAB members] is trying to think about the Web as an application platform.
Larry: We cam up with an architecture of web applications. We haven't had the bandwidth. Could we collaborate on - e.g. security architecture, sandboxing - the thread analysis crosses protocol boundaries.
Noah: Next steps?
Alexei: IAB is trying to get an IAB presentation for Prague IETF. [Prague is 3rd week of March]
<tlr> I think I'll take an action to (re)introduce Tim, Noah, Hannes, John, Olaf
Larry: the tag could offer to
collaborate with the IAB on a plenary presentation to IETF on
Web Application Architecture.
... Schedule telecon time.
<scribe> ACTION: Larry to prepare us for a teleconference with IETF-IAB on possible prague IETF presentation. [recorded in http://www.w3.org/2010/11/04-tagmem-minutes.html#action01]
<trackbot> Created ACTION-497 - Prepare us for a teleconference with IETF-IAB on possible prague IETF presentation. [on Larry Masinter - due 2010-11-11].
Thomas: Long-standing position
(in IETF and W3C) that https is a mistake...
... there are 2 RFCs on how to http and tls together - the
standards-track one says you should use http upgrade to
establish tls - as you do with all other protocols.
Tim: you always go in on port 80.
Thomas: in this case there is no
such thing as https.
... the other RFC (informational) says use HTTPs - new URI
scheme - that is the one that is deployed.
... the document object models you have have different
assurance levels. An important security property.
... so we have and approach that is out of line with all other
protocols- but out of that we have an result that is part of
the Web security model - unintentional.
... many are saying that upgrade is preferable.
... given other dependencies (e.g. scripting environments)
[this is a complex domain].
... we need to consider this together [possibly with IAB].
Tim: In alternative, do you use http as the URI?
Thomas: you use http.
... the upgrade is opportunistic.
Noah: One of the things we would lose then would be e.g. banks being able to hand an identifier to me that implicitly says "this is secure."
Dan: Most banks don't give you a readable https URI...
Noah: Many sidtes do...
Thomas: it's true to say that https takes care of the external signalling piece.
Noah: These are different namespaces because of what we're talking about here. The space of http names are not protected. The space of names that use https do have an extra level of protection.
Tim: It's a common myth that it's
important to keep the authentication and authorization
separate.
... the way the system works at the moment [is what Noah
said.]
... this cause problems - e.g. in the semantic web.
<Zakim> DKA_, you wanted to wonder what the appetite of the Web community to adopt a different approach?
<noah> DKA: Is there any appetite in the Web community (user agent providers and users) to move in this direction?
Thomas: the point I'm getting at
- the use http to do upgrade approach lingers as
architecturally superior. There is work ongoing that would
enable some useful upgrade-like behavior to occur. What I
wanted to float: the "but you should do upgrade" approach could
appear again.
... Articulating clearly what the architectural value fo the
current distinction is would be useful [to these new
efforts].
Noah: I think this would be [useful to work on].
Ashok: problem I'm seeing is that there is lots of current usage.
Noah: Tim pointed out that there are also some problems with current practice.
Tim: The idea on the Web is that a URI is all you need. You can follow your nose - look up specifications recursively to find out what was intended.
<noah> Noah: I specifically said this seemed like the sort of question the TAG might work on, I.e. whether security of name resolution and of communication to the resource should be signaled in the identifier
Tim: any system where you have to caveat a URI with extra instructions [is broken].
<noah> Tim: when it's not in the Idenfitier, the breakage moves to worse places, such as shref="..."
Adjourned
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/community/W3C community/ Succeeded: s/mine/Larry's mime-web-info/ Succeeded: s/Nah// Found Scribe: Dan WARNING: No scribe lines found matching ScribeNick pattern: <Dan> ... Found ScribeNick: DKA Found ScribeNick: DKA_ ScribeNicks: DKA, DKA_ Present: Ashok Thomas_Roessler Tim Larry Noah Yves Dan Alexei WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/04-tagmem-minutes.html People with action items: larry[End of scribe.perl diagnostic output]