<DanC> Date: 6 Nov 2009
<scribe> scribenick: timbl
[Instituting more of a policy of protocol review of W3C activities. ]
Noah: How is W3C organized to deal with security?
DanC: T&S domain tends to specialize in security. There was a Web Security Context (WSC) working group which did the browser chrome thing. There is no generic horizontal security activity [like acc'y or I18n].
Noah: So the TAG is the only general group looking cross-wg..frightening
LM: Security is not a a specialty of the TAG. The IETF has a Security directorate, and every document has a threat analysis and mitigation review.
DanC: a new mailing list and/or wiki maybe coming out of the lunch security BOF.
LMM: Some people thought the overhead of IG would be too big. But f there were such a group, then there would be many people from member companies who would participate. I suggest we the TAG endorse this.
<masinter> ... and encourage W3C staff to pursue this because the TAG isn't prepared to do the security architectural work that needs to be done.
<DanC> +0 on endorse...; it sounds well and good, but ...
Ashok: Security on the web, or device security too?
LMM: Wherever W3C does work.
<Zakim> noahm, you wanted to noodle on security entry in Web apps "Table of Contents"
Noah: Two things one of which is
yes i think it would be good for us to agree that we should
help people [lost]
... we could find a tag member who could spend some time thinking about this. I hear l Larry say security is important, and we should say security is something that w3c should do better, but he didn't say that the tag should offer, yes if you want is to we will tell you what you think of your security issue.
<trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to update Web Application architecture outline based on discussions at TAG meetings -- due 2009-10-31 -- OPEN
DanC: CORS and Origin Header .. seem close to security
Larry: Suggest we ask Thomas to report
ACTION DanC as Thomas for a report form the security BOF
<trackbot> Created ACTION-323 - As Thomas for a report form the security BOF [on Dan Connolly - due 2009-11-13].
<DanC> ACTION: DanC to invite Thomas to report on actions from TPAC security BOF
<trackbot> Created ACTION-324 - Invite Thomas to report on actions from TPAC security BOF [on Dan Connolly - due 2009-11-13].
<ht> From Mike Smith, authored (?) by Anne van K., minutes from the security BOF: http://www.w3.org/2009/11/05-security-minutes.html
Noah: In December I want to crank up our focus on Metadata.
Ashok: We are stalled .. how should we move this forward. Thinking about device APIs ...
Noah: Broader than that .. a full road map of web applications, including security.
[discussion of pressure of work and scheduling]
Noah: We meet on December 1. Let us review it before, November 19?
<DanC> action-306 due 1 Dec
<trackbot> ACTION-306 Work with JK and AM to update Web Application architecture outline based on discussions at TAG meetings due date now 1 Dec
Larry and Ashok will meet Nov 17 18 and the TAG will get it on 1st and discuss it on the face-face on the 6th
HT: As there was agreement about the substantive point, we didn't need maybe to spend 45 minutes discussing the polyglot issue, but in fact I think it was useful.
Noah: We went though the agenda we brought with us and got though most of it.
HT: I found it interesting that many influential member of the HTML5 WG seem to have very little awareness of the document and content management industry, which has largely switched to end-to-end XML over the last few years.
Timbl: Some people in the HTML group committed to do their best to expand the polyglot overlap to be as big as possible. I applauded that move, as the polyglot language is really valuable. Noted that Kai/Deutche Telecom pointed out that his whole site was polyglot.
<masinter> Polyglot documents are *not* defined in the document, and so the commitment to make sure they are allowed in the document is insufficient.
<DanC> it was news to me that Karl had written something about "versatile" documents (aka polyglot documents)
Timbl: It was pointed out that there was a large XML-using community who have web pages and want them to be XML.
<timbl_> That's it
<DanC> note also "First Polyglot Validator Check Deployed" http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed
<masinter> The text/html MIME type should reference the description of polyglot documents which is currently not in the text/html MIME type registration
HT: I noted in corridor discussion that if you are using digital signature with your XML documents, converting them to HTML syntax for transmission is not an option.
DanC: I think the community has evolved its understanding of what is acceptable.
<DanC> DanC: two things: (a) whether formerly valid stuff is now invalid and (b) whether history is preserved; I think (a) is acceptable and hixie claimed history section of HTML 5 subsumes the history in the RFC. so if they don't change anything, I'm satisfied.
Larry: The place where the the IANA considerations for MIME type registration, section 31.1 ..
[discussion of section 13.1]
Larry: This doesn't say that the
previous document types under earlier versions of HTML are
... RFC2854, under 'published specifications' it explained it.
Noah: In practice the goal of the spec is to include the older languages
Larry: I don't believe that the HTML5 document does currently clearly define a language which includes all others
DanC: Specifically, an example if that the @profile attribute has been removed, when it was in HTML4.
<ht> Combining "This document is the relevant specification. Labeling a resource with the text/html type asserts that the resource is an HTML document using the HTML syntax." with "XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]" we don't have a satisfactory state. If the
HT: This [above] is what Hixie promised to change, until it is changed we can't evaluate the result.
<scribe> ACTION: HT to Assign himself an action to track the text """urce with the text/html type asserts that the resource is an HTML document using the HTML syntax." with "XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]" we don't have a satisfactory state. If the"""
<trackbot> Created ACTION-325 - Assign himself an action to track the text """urce with the text/html type asserts that the resource is an HTML document using the HTML syntax." with "XML documents that use elements or attributes from the HTML namespace and that are served over the wire (e.g. by HTTP) must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html. [RFC3023]" we don't have a satisfactory state.
<DanC> (Henry, I'm not sure there's a bug on the media type stuff; the/a bug Sam opened right away was w.r.t. web addresses)
<ht> I found it, its http://www.w3.org/Bugs/Public/show_bug.cgi?id=8154
<ht> ACTION Henry S to track HTML WG progress on their bug 8154 on polyglot documents, due 2009-12-05
<trackbot> Created ACTION-326 - S to track HTML WG progress on their bug 8154 on polyglot documents, due 2009-12-05 [on Henry S. Thompson - due 2009-11-13].
LMM: I think the microdata stuff should be not only factored out but removed as out of HTML WG charter scope; to pursue it involves a charter change or a new WG
TimBL: Lets as a the TAG file a bug in real time now requesting the removal of the the Microdata section, and remove it (with no normative reference).
Because ... [collecting rationale in IRC...]
<noahm> Modularity is beneficial in this case. There are alternative technologies such as RDFa, and separating specs for metadata is a good thing.
<DanC> RDFa is in considerable and increasing deployment (before saying it's a REC)
- The modularity of the document is damaged. The issue of putting data into HTML5 documents is sufficiently separate functionality that it would be better to have a separate document which people interested in data can review without having to read the rest of the space.
<masinter> Metadata architecture is complex; real world widely deployed metadata management systems have found that distributed extensibility is even more important for metadata than for markup, since each organization and community has different desires for metainformation even if they share common understanding of the data.
<noahm> the modularity of both the design and the documentation of it is damaged
- The microformat bits in fact overlap with, and would need review by , dramatically separate communities such as calendaring (iCalendar etc), contact (vCard etc).
<Zakim> DanC, you wanted to consider endorsement of http://lists.w3.org/Archives/Public/public-html/2009Oct/0773.html
<masinter> The embedding of this specification within HTML5 hinders the involvement to the web content management community.
[discussion of fine tuning of the bug]
RESOLUTION: To endorse http://www.w3.org/html/wg/tracker/issues/76 and file a bug for removal of the Microdata section form HTML4.
<ht> The HTML Bugzilla bug for "remove microdata" filed by the TAG is http://www.w3.org/Bugs/Public/show_bug.cgi?id=8220
HT: This felt awkward to me from
... But I hear it seemed to go well.
... I have a better sense of where people who oppose NSs think the costs are.
... That is, the cost of the tuple representation of names at the API level; and also the syntactic overhead of managing them, and vulnerability from lexical scoping when you are cutting and pasting.
<DanC> (re tuples as names, the XML community is hoisted by its own petard in that case; if they'd just combined them into one URI, this wouldn't be a problem.)
HT: The other issue, with a
different character, raised by Larry, was about where you buy
into the "decentralized" part at all. There was actually much
less of the Henri's "We have done all the extensibility we
... Going forward, we have a much better sense of how to frame arguments.
Larry: Either the costs reduced or the benefits outweigh them.
TimBL: Meanwhile these "Unobtrusive Namespace proposals"
DanC: That doesn't do anything for me
HT: MY reading is that:
... there are two classes of proposal:
<DanC> (Liams's proposal with outboard namespace declarations doesn't meet the http://www.w3.org/TR/NOTE-webarch-extlang#Ambiguity requirement, aka lexical scoping)
HT: 1) Liam's for example is to
make it easier to change the default ns withing certain scopes.
There is an out-of-band description of how to do this, but in
well known situation they can be hard-coded, like HTML.
... 2) Or there is an appeal to out-of-band information, which is used to set up non-default prefixes, like SVG: "Media type derived namespace declarations".
TimBL: These all follow from the media type.
HT: ... I prefer (2)
<Zakim> noahm, you wanted to talk about Liam's proposal
<DanC> (perhaps I read a version of Liam's proposal that's so old that it doesn't bear on this discussion; pointer to modern version, please?)
Noah: What I like about Liam's is
that it gives you NS and also allows you to evolve a tag from
an experimental namespace into a new version of a well-known
... (BTW Liam had sent his idea to the Hypertext Coordination group, which had not been an effective place, but now it is sent t the HTML WG)
HT: Option 2 has never been
really written down.
... That ^^ was a version of Liam's proposal.
DanC: The current HTML5 spec is an example of one of these.
Larry: Henry, Could you submit a bug to the HTML WG that you would like this?
HT: First I need to read Tony Ross's proposal. (linked from the agenda or from noah's talk which is)
<DanC> further discussion showed that Dan had a different "these" in mind and the HTML 5 spec isn't an instance.
<ht> ACTION Henry to review Microsoft's namespaces in HTML 5 proposal
<trackbot> Created ACTION-327 - Review Microsoft's namespaces in HTML 5 proposal [on Henry S. Thompson - due 2009-11-13].
DC: Tim, do you believe their use cases cover any of the interesting cases?
Tim: yes, e.g., they demonstrated on a very large SVG file; demonstration was that it loads 200 times faster
Noah: We we not sure of the original speed analysis of these but I don't think we have any issues now
[agreed generally, so we move on]
Noah: We asked them to register a content-encoding value and they have, so we should thank them.
HT: We were worried that, because the encoding actually is lossy in that that the double quotes on attributes become single quotes, it wouldn't be accepted by the IESG, but it was.
<noahm> Proposal: the TAG thanks the EXI working group for registering the exi content-coding. Your registration completely resolves the concern we expressed in Mandelieu
PROPOSED: We thank the EXI WG for registering the content encoding and encourage them in their endeavors.
<noahm> Either is fine with me.
<DanC> "exi" is registered; I don't know whether it's case sensitive
<noahm> I note that this >is< what we encouraged them to do.
TimBL: Oh dear, another nail in the coffin of the plot to use double quotes for all attribute values except single quotes when it is a qname ;-)
<DanC> (if the rationale is "this is what we asked them to do" then I need a pointer)
RESOLUTION: We thank the EXI WG for registering the content encoding and encourage them in their endeavors.
<DanC> for reference, exi registration request http://www.alvestrand.no/pipermail/ietf-types/2008-October/002103.html
ACTION Noah convey to the EXIWG the resolution "We thank the EXI WG for registering the content encoding and encourage them in their endeavors.".
<trackbot> Created ACTION-328 - Convey to the EXIWG the resolution "We thank the EXI WG for registering the content encoding and encourage them in their endeavors.". [on Noah Mendelsohn - due 2009-11-13].
NM: seems we should do webapps architecture at our Dec f2f meeting
<DanC> (TOC, for ref http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921 )
NM: Raman will not be there at the Dec f2f meeting
<masinter> scribenick: masinter
<noahm> Ashok will help Raman frame the F2F agenda and preparation on Web Application Architecture
[postscript: see ACTION-306 and ACTION-337]
<noahm> Ashok will frame the F2F agenda and preparation on metadata access
[postscript: see ACTION-336]
<noahm> :Larry will frame the F2F agenda and preparation on metadata formats/representations
[postscript: see ACTION-337]
<trackbot> ACTION-321 -- Larry Masinter to lightly edit TAG input to DAP WG per 8 Oct and tell Noah -- due 2009-10-29 -- OPEN
<DanC> action-321 due next week
<trackbot> ACTION-321 lightly edit TAG input to DAP WG per 8 Oct and tell Noah due date now next week
<noahm> ACTION: Noah to schedule F2F of Henry's work on referencing changing specs
<trackbot> Created ACTION-329 - Schedule F2F of Henry's work on referencing changing specs [on Noah Mendelsohn - due 2009-11-13].
<noahm> Dan volunteers best effort to do early versions of the agenda for F2F.
<noahm> Noah thanks him >profusely<
<DanC> ACTION: DanC to prepare Dec f2f agenda in collaboration with Noah etc.
<trackbot> Created ACTION-330 - Prepare Dec f2f agenda in collaboration with Noah etc. [on Dan Connolly - due 2009-11-13].
Noah: Unfortunately, we didn't get to on stage called for nominations to the W3C TAG.
<DanC> scribenick: DanC
LM: I reviewed widget:
... reported to webapps widget subgroup...
... reviewed it from the p.o.v. of an author of IETF guidelines on making new URIs
... i.e. not exactly a TAG review or Adobe review
... I'm surprised that the WG considered it done
... e.g. several things "out of scope" but URI registration guidelines requires that things be well-defined; "out of scope" isn't well-defined
[[ AWWW Suggestion: add guideline: "Make New URI Schemes Reusable If You Can't Reuse URI schemes".
LMM: perhaps thismessage: could
have been extended, rather than making a new URI scheme.
... it's from MIME multipart
... for references between MIME parts
<timbl> ... The thismessage: URI scheme is a neat URI scheme which does actually work and i widely deployed
<timbl> ... You can make relative URIs but they don't resolve to anything except relative the message.
<timbl> ... If you have message within message then you flatten it.
TBL: yes, that AWWW suggestion appeals to me.
<timbl> LMM: I suggest in my review adding to AWWW the advice "i you can't reuse another r scheme, and then if you can, make you new scheme re-=usable".
HT: thinking about the impact on implementers...
<timbl> Tim: The document should have real-life examples.
HT: old implementations of the extended scheme won't necessarily be updated
<timbl> Noah: We would normally start with a finding for this sort of thing.
<scribe> scribe: timbl
LMM: The draft charter for IRI is
to update the guidelines for new URI schemes.
... I withdraw the suggestion.
LMM: ... I met with the I18n
group on Tuesday, and had dinner last night with 14 people
discussing IRIs, in the unicode consortium, Lisa Dusseault
(sp?) , Mike Smith
... Mike was to represent the HTML5 contingent in this.
<DanC> (note to self... brief MikeSmith on HTML 5 URI design details... maybe I'll action myself... noah, do you mind?)
LMM: It looks very positive for
agreement hat there should be a WG in the IETF wit aggressive
... with that [linked] as draft charter.
DanC: Any chair candidates?
<masinter> volunteers to help with chairing, managing the issue list, shepherding the various working groups involved
LMM: I count 9 committees who are
interested in what IRIs are. They are listed at the end of the
... I added ICANN.
... This is the one committee to rule them all and in the darkness bind them.
LMM: Right now, what web browsers
will accept in a href="here" cannot be put in other service
which take URIs. There is a specified mapping in the document
which was posted, in a new versions of the IRI-bis document,
which ... [lost]
... This IRI-bis document defines in section 7 a processing model to handle otherwise invalid IRIS which will make an IRI out of any string.
... In the definitions, in section 1.3,
... It defines LEIRI and Web-ADDRESS as strings which might otherwise survive such processing.
... : ... section 7.2 ...
... One needs to find a better name/abbreviation for these ..
HT: This works for me
LMM: This is my cut at the knot.
<DanC> (the word "survive" isn't in the document... ah... "acceptable input to the processing rules in Section 7.2.")
<trackbot> ACTION-298 -- Larry Masinter to notify the TAG of the next IRI draft -- due 2009-09-16 -- PENDINGREVIEW
TimBL: Can you remove the // while you are at it? ;-)
<DanC> close action-298
<trackbot> ACTION-298 Notify the TAG of the next IRI draft closed
<ht> Here's the HTML WG Issue for web addresses: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8207
<DanC> (our iriEverywhere issue is now open with no actions, which bothers the pedant in me, but I can't think of... ah... NM is pursuing it.)
<DanC> close item 7
<DanC> close item 10
HT: At the Director's insistence,
when the XML proc model was chartered, it was chartered to do
two things, what ht group wanted to do, which was a new
scripting language, and what the Director [and DanC] wanted as
well which was to define the default processing model of an XML
... HT: I decided eventually there was very little one could say about the default processing mdoel... and Norm Walsh and I wrote it on he back of a napkin yesterday.
<masinter> danc, iriEverywhere -- suggest we ask W3C I18N to produce Rec which points people at IRI and updates http://www.w3.org/TR/charmod-resid/ and LEIRI etc.
HT: This is space whcih ther spcs
can be iused to explain what the input to t epropcess is. It
does Xinclde,. It says you must process the external subset. It
saif you muse updat ethabse URI of documents, and annotae al;
XML ID elements with ID specs. So there is just one consequent
of any incoming XML document.
... That is consequent as a n infoset.
TimBL What about decryption?
<trackbot> ISSUE-34 -- XML Transformation and composability (e.g., XSLT,XInclude, Encryption) -- OPEN
<trackbot> ACTION-239 -- Henry S. Thompson to alert chair when updates to description of xmlFunctions-34 are ready for review (or if none made) -- due 2009-12-01 -- OPEN
HT: This resolves a 10 -year old
ambiguity that there is not one defined infoset associated with
... YOu don't ahev to use it.
TimBL: Then how doe sthe receiver know whether to?
<DanC> DanC: "default" is a misnomer, then
<DanC> HT: I can see that.
LMM: Chris LIlley reminds me that there was going to na an update teo the application/xml and so the default processing model could be mentioned here.
Noah: What about the Follow Your Nose question? How to get to teh set of specs from the document you receive? This dooesn't seem to solve that problem.
<Zakim> noahm, you wanted to say this goes half way
LMM: You could urge a spec writer to define the rpocessingmodel from the MIME spec.
Noah: This best practice for xml applications ike purcase orders they do this.
<DanC> (the best way to say that this isn't _the_ only one is to document 2. I think the "what you see is what you get" processing model should get at least equal, if not preferred, footing. i.e. no external anything)
Noah: We wil lhave teleconferences in the 12 and 19th. Regrets from Noah for the
<DanC> taking a look at http://www.w3.org/2001/tag/group/track/agenda ... organizing actions by issue/product...