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: 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.
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 community - e.g. the chairs list and www-tag.
... 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.
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#action02]
<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.
Nah
s/Nah//
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?
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.
... any system where you have to caveat a URI with extra instructions [is broken].
Adjourned
<Ashok> Scribenick: Ashok
Dan: The Geolocation spec has some privacy requirements now
... we should ask them what their plans are re. privacy
Larry: Re.privacy ... we should schedule a review after we read the position papers for the workshop
Noah: I have an action to ask Tomas whether I could attend the Workshop
... I will report back on the workshop
Dan: I am working on a position paper with a colleauge from Vodafone
s/colleauge/colleauge/
Dan: I would like to take an Action to work on a finding on 'minimization'
Noah mentions opportunity costs
Noah: Did we learn anything from the WGs that we want to work on
Noah: Paul said "we are going to determine and resolve all our issues before we go to last call". May not get agreement from the raiser that the issue has been resolved to his satisfaction
<Zakim> noah, you wanted to report on what Paul Cotton said
Noah: I had an action re, terminology in the HTML spec re. conformance in the case where there are extensions
... the spec says 'applicable specs may be used to create extension' then tere is some langauge that I am unhappy with
... seems like the user can decide what is conforming
... they need better wording re. conformance
... I raised the issue and it will be discussed at 4pm today
LM: Questions what they say
Noah: I'm talking about deltas ... extensions
<lmm> think the issue comes down to why you define 'conforming document' and what the interoperability consequences of that definition is
Noah: They seems to say that you are conformaing if you want it be
s/conformaing/conforming/
<lmm> normally the benefit of defining 'conforming document' is that 'conforming documents' will work with 'conforming document readers'. Allowing arbitrary extensions to 'conforming document' will break that interoperability promise
Noah: They have diluted the meaning of 'conformance'
... I think we are agreeing
LMM: I comes down to the conformance of the document
<lmm> there isn't an issue with conforming readers also implements extensions
LMM: It is not a problem for readers
<lmm> or is it? it depends on the nature of the extensions?
Noah: There is no bound to the changes I can make ... I can replace < with (
<lmm> if the 'extension' actually changes the behavior of existing conforming documents, then the 'applicable specification' probably isn't conforming
Noah: Say that 'this doc conforms to HTML and this extension document'.
LMM: Can extensions change existing behavior?
Noah: I don't think that is ruled out
<lmm> too many meaningless terms in this
<lmm> "authors must not" -- should be "conforming documents must not"
Noah: This is their issue 140
<trackbot> Sorry... adding notes to ISSUE-140 failed, please let sysreq know about it
<lmm> suggest change proposal that just removes the text that doesn't add to the value of the specification
Noah: Larry argued we shd set goals and dates
... we are working in parallel on a bunch of stuff
<lmm> want to go back to HTML discussion we just had, to suggest we write a change proposal, with due date ... Jan 15
Noah: Perhaps look at work on Web Apps and pick one or two topics and ask whole TAG to work on it
... so when a draft comes out people will read it and comment on it
LMM: We shd discuss what will our product be
... Re. HTML issue we shd create a change proposal
Noah: I did create a change proposal
... and put it in Bugzilla
... they put aside and I raised an issue
LMM: We should not schedule discussion unless we have a document
Ashok: I think some brainstorming is good
<lmm> In this particular case, I think we should schedule the TAG to develop the change proposal
Noah: I would like to try this
LMM: In the case of the HTML issue, unless it is resolved to our satisfaction the TAG should create a change proposal
<lmm> i am saying that we should not talk about things that we're not willing to "engage" on
Noah: Explains the history
LMM: Disagrees with what happened
Noah: If TAG has an interest in this we can pick it up and pursue it
LMM: If issue not resolved to our satisfaction, TAG shd create a change proposal
Noah: There is a change proposal ... I can bring it to the TAG
<lmm> consider possibly finding on versioning specifically on extensions
Ashok: Yes, if we can bound it
<trackbot> Created ACTION-498 - Report results of HTML5 WG consideration of conformance for extensions (their ISSUE 140), get TAG to prepare change proposal if necessary Due: 2010-11-16 [on Noah Mendelsohn - due 2010-11-12].
Noah: You shd not be able to claim conformance if your doc does not conform to the unextended spec
LMM: Will the doc be parsed by a conforming reader
<lmm> there might be two levels of "conforming document", based on the "ignore any element or attribute you dont understand"
<lmm> the current text doesn't seem to enforce the interoperability requirement between "conforming documents" and "conforming readers". the question is whether an "applicable specification" might make a currently "conforming reader" into a "non-conforming reader"
Noah: Conforming readers accept all bit streams
LMM: But must accept in a conforming sense
Noah: Larry, you can go further than I have done
... They are not interested in pushing 'HTML conformant' ... if the committee thinks it conformant then it is conformant
... Be explicit about what it conforms to
LMM: Alexey said the IESG noticed that the Web was becoming an app platform and wanted to get involved in relevant architectural issues
... Alexey said they were going to schedule discussion at the Prague mtg of IETF ... wondering if TAG should prepare a paper to deliver at that conference
Ashok: What's the deadline?
Dan: A deadline may help
LMM: I am going to the mtg and can present
Yves: I would be good to show that TAG is interested in this area
<lmm> propose ACTION: Larry to coordinate with Alexey about a possible presentation, come back to TAG with ideas
Noah: I like the bounded scope
<lmm> product: presentation & slide deck ready by March 15
Ashok: Discussion about how tracker is broken
<trackbot> Created ACTION-499 - Prepare product description page for work on IETF presentation. [on Noah Mendelsohn - due 2010-11-12].
<trackbot> Created ACTION-500 - Coordinate with Alexey about a possible presentation introducing IETF to TAG work on Web Apps & report to TAG [on Larry Masinter - due 2010-11-12].
<trackbot> ACTION-500 Coordinate with Alexey about a possible presentation introducing IETF to TAG work on Web Apps & report to TAG due date now 2010-11-30
<trackbot> Created ACTION-501 - Follow up on whether GeoLocation finds reasonable answer on giving permission per site/app etc [self-assigned] Due: 2011-03-01 [on Noah Mendelsohn - due 2010-11-12].