W3C home > Mailing lists > Public > www-tag@w3.org > October 2009

Minutes of 23-25 Sept 2009 TAG F2F now available

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 16 Oct 2009 16:36:12 -0400
To: www-tag@w3.org, public-tag-announce@w3.org
Message-ID: <OF822B8B94.7132BA6D-ON85257651.006DA78C-85257651.00712E26@lotus.com>
Unapproved draft minutes from the F2F meeting held by the TAG from Sept. 
23-25 2009 are now available.  Links to records of individual discussions 
are available from an updated copy of the agenda page [1], and for most 
readers these will be the easiest way to find items of interests.  The 
agenda links are into the complete records for the respective days [2-4]. 
Text-only copies of the minutes are also appended to this email.  I expect 
that the TAG will consider approving these as a true record during our 
teleconference on 22 October.  Thank you.


[1] http://www.w3.org/2001/tag/2009/09/23-agenda
[2] http://www.w3.org/2001/tag/2009/09/23-minutes
[3] http://www.w3.org/2001/tag/2009/09/24-minutes
[4] http://www.w3.org/2001/tag/2009/09/25-minutes

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142


      [1] http://www.w3.org/

                               - DRAFT -

                 TAG Sep 2009 meeting in Cambridge, MA

23 Sep 2009


      [2] http://www.w3.org/2001/tag/2009/09/23-agenda.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/09/23-tagmem-irc


          DanC, TimBL, ht, jar, jkemp, lmm, noahm, Ashok


          Noah Mendelsohn

          John Kemp, Larry Masinter


     * [4]Topics
         1. [5]Convene, Review Agenda
         2. [6]HTML, collecting issues
         3. [7]references to versioned specifications (HTML 5 review
            topic #15)
         4. [8]Architecture of Web Applications
         5. [9]HTML issue collection, cont
         6. [10]document conformance vs. user agent conformance
            requirements (#13)
         7. [11]discussion of work on webapis
         8. [12]wrap up for the day (agenda review)
     * [13]Summary of Action Items

Convene, Review Agenda

   <jkemp> scribe: John Kemp

   <jkemp> scribenick: jkemp

   nm: (reviews "review goals" + agenda)
   ... discuss HTML5, and what (if any) feedback we want to give to WG
   ... review and make progress on items agreed at last F2F
   ... discuss TPAC logistics
   ... TPAC program committee wants to organize a session on
   "decentralized extensibility" and has asked me for help in framing
   the session
   ... not limited to the sessions and goals listed

   ht: would like to keep slot on naming

   lmm: would like to talk about IRIs

   nm: (review each slot)

HTML, collecting issues

   nm: notes the relatively new HTML 5 "authoring specification"

   nm solicits HTML 5 spec issues to discuss; builds a list:

     [14] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

   lmm: redefinition of text/html MIME type is one issue - would help
   to have common understanding on use of MIME types
   ... issue of error handling came up in a specific URI parsing case
   ... a lot of these error handling questions reduce to "what is the
   role of a standard or specification"?

   tbl: you want to discuss whether the error handling is defined in
   the specification?

   lmm: (roughly) yes

   <masinter> how it is defined

   nm: reviews JK issues

     [15] http://lists.w3.org/Archives/Public/www-tag/2009Sep/0012.html

   jar: HTML5 has some innovations in how the specification has been
   ... to what affect does W3C want to carry through some of these?

   nm: and use use-cases to illustrate where particular innovations
   work and don't work

   lmm: problem that arises when normative algorithm is used to give
   ... instead of giving invariants which would be exhibited by
   applying an (or different) algorithm(s)

   ht: impact of script and document.write

   danc: drag and drop and relationship to bibtex, vcard

   am: commented about how they talk about datatypes - using prose
   instead of BNF

   lmm: conformance requirements which are not testable

   ht: my related point is that there is a notion in the HTML spec is
   that document conformance and UA conformance are decoupled
   ... not sure that this is achieved
   ... and whether the goal is a good one

   <noahm> What I've recorded is: "The spec seems to decouple "user
   agent conformance" and "document conformance". Stipulate that's a
   good goal. There's a question of whether the spec. actually achieves
   this. Was it a good goal in the first place?"

   lmm: outline section has no exhibited behaviour in other parts of
   the spec.

   jar: OWL spec. has this issue too

   ht: XML schema too
   ... W3C-wide issue about references to other specifications, also
   exhibited in HTML
   ... don't follow guidelines suggested by Sperberg-McQueen
   ... MUST support at least version X, MAY support version Y, for

   <DanC_lap> (the References section of the HTML 5 spec is fairly new;
   I took a look at it, and I think it does a reasonable job on the
   versioned specs issue)

   nm: difference between "you've got a buggy processor" and "you've
   got a processor that supports a version we haven't seen"

   lmm: seems to be some assumption that a WG will remain active for
   the indefinite future to update the specification as refs change,
   for example

   ht: have we decided about use of the term URL?
   ... and the 'ping' attribute?

   <DanC_lap> hmm... no Zakim... how about RRSAgent? nope... jkemp,
   note w3.org hasn't logged the proceedings so far

   lmm: the "willful violations" sections - charset override in

   <Zakim> DanC_lap, you wanted to add registries to the list: rel
   values in whatwg wiki, Public Suffix List from Mozilla

   ht: was assigned a section about scripting
   ... execution model is opaque to me - can we discuss?

   lmm: several examples in mind - the general issue is about
   applicability of the Web
   ... public Web vs. private Web (intranets et al) vs. use of Web
   components for things "other than the Web"

   <DanC_lap> (yeah... this "only the public web matters" position
   seems iffy to me. I tried to blog about it, but the comments suggest
   the point didn't get across well.)

   lmm: public Web split between "crawlable" vs. that which requires
   ... applicability of <canvas> in environments such as email

   jar: javascript URI scheme is in the spec. but not registered

   nm: is your issue only about registration?

   jar: if done, it should be done properly

   <noahm> My initial list of issues was sent to the TAG here:

     [16] http://www.w3.org/2001/tag/2009/09/TagHTMLIssues.html

   <timbl> paving cowpaths Having spent quite some time in a country
   where the roads are in fact paved cowpaths, ... I know how twisted a
   road you can end up with :)

     [17] http://www.theotherpages.org/poems/chester1.html#2

   nm: link rel issue: spec calls for processing to continue in a case
   that they say is "not allowed"

   <DanC_lap> (I thought we dispatched with this one ("rel attribute
   must... if rel is absent..."). editor ack'd as bug and fixed it.)

   ht: this says that the "document is not conforming", but tells the
   UA what to do in that situation

   nm: document.write cannot be used with XML serialization
   ... I have an XML DB to manage my HTML, and can serialize as XML,
   but also want to use document.write

   lmm: execution toolchain - content not written only by people
   writing HTML (tools are often XML-based)
   ... and use-cases that led XHTML WG to do modularization
   ... being able to subset the specification was a requirement

   nm: content sniffing?

   ht: IETF has taken this on

   lmm: would still like to talk about this in relation to the use of
   MIME types
   ... register a MIME type to allow sender to tell recipient what
   sender means
   ... and... division of responsibility between W3C, IETF and also WGs
   in W3C
   ... Origin header, content type sniffing, URI schemes are examples

   nm: would like to mention issue of inconsistent (in)formality of
   parts of the spec. - borderline editorial

   am: some of these things are bugs, others are "meta" issues on the
   whole spec.

   nm: anything can be reported individually to the WG

   lmm: which of these issues are we willing to commit to as a group?

   nm: I feel obligation to discuss things we think are important

   <noahm> Larry has expressed the concern that the HTML draft is, in
   some cases, intentionally provocative, e.g. the statement that "A
   DOCTYPE is a mostly useless, but required, header." There is a
   perception that this is disruptive.

   <noahm> [18]http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

     [18] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt

   <noahm> [19]http://www.w3.org/2001/tag/2009/09/htmlissues.pdf

     [19] http://www.w3.org/2001/tag/2009/09/htmlissues.pdf

   nm: identify 5 things from the above list to discuss first
   ... everyone gets 10 votes, can assign multiple votes to one issue,
   don't have to use all votes

   <DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28

   <DanC_lap> hmm... 4+5 cluster, 7, 11, 15+20 cluster, 25. 26, 28, 31

   <timbl> Tim: 5: 4; 7:3; 11:2; 12:1

   <masinter> 1,1,3,6,10,13,19,25,28,31

   <jar> jar: 1,3,4,7,10,13,27,28,30

   (group voting on issues as listed in

     [20] http://www.w3.org/2001/tag/2009/09/HTMLIssues.txt)

   <DanC_lap> 3 on 15 (+20), 2 on 25, 2 on 26, 28, 31 (revision after
   realizing there's more than one choice per issue)


   issues 7,13,15 get the most votes

references to versioned specifications (HTML 5 review topic #15)

   dc: when you link to a versioned spec. you are delegating authority
   to some other spec.
   ... link to a static spec. it's like loading a library

   ht: there is a difference between "you must use the latest" and "you
   must use some version either this dated one, or later"

   dc: 2 instances in HTML - allowed rel values specified to be in
   WHATWG wiki
   ... second is mozilla decided to create a public suffix list (.com,
   .co.uk etc.)

   tbl: if you're looking for the legal owner of the URI go to this

   <masinter> [21]http://dev.w3.org/html5/spec/Overview.html has
   reference [PSL]

     [21] http://dev.w3.org/html5/spec/Overview.html

   tbl: so that delegation of authority is clear

   <masinter> search for "Public Suffix List"

   <masinter> 2.4.9 Reversed DNS identifiers : #

   <masinter> Check that the end of the resulting string matches a
   suffix in the Public Suffix List, and that there is at least one
   domain label before the matching substring. If it does not, or if
   there is not, then the string is not valid; abort these steps. [PSL]

   tbl: below that, delegation is not open

   dc: browser can then tell you "who owns the page"
   ... I think this shows up in the origin work
   ... feedback from IETF was "don't do that"

   <masinter> "6.4.1 Relaxing the same-origin restriction"

   lmm: (inserting into IRC some refs to "informal registries")
   ... spec. incorporates by value in some places - eg. vcard - one
   kind of versioning
   ... also applies to HTML use of URIs
   ... then, the case of a normative ref to another specification


     [22] http://www.whatwg.org/specs/web-apps/current-work/#references

   ht: worth nothing that when we reviewed the spec, there was no
   references section

   <DanC_lap> (interesting... the public suffix list seems to be used
   in the reverse domain label stuff in the microdata stuff)

   <DanC_lap> (and only there. never mind what I said about origin and
   javascript security boundaries.)

   ht: refs are, for example, undated

   <masinter> danc: that's only in one version

   ht: URIs are undated, but reference itself has a date
   ... what happens when newer versions come out?

   nm: so you're saying that the ref is dated, however the URI links to
   the "latest" version?

   ht: yes

   <jar> the hyperlinks (not visible in printed version) are
   non-normative, I hope?

   <DanC_lap> recent discussion suggests printed versions are not
   considered usable by implementors; so in effect, the links _are_
   normative; i.e. they impact interoperability. (see msg from maciej.)

   <DanC_lap> (darn; can't confirm from archives re printed versions)

   nm: what do I need to do to see if my user-agent is conformant or
   ... in cases like this, where references are unclear, that
   conformance is also unclear
   ... comment might be that this is ambiguous and should be clarified

   <jar> in the [XMLBASE] case the printed text says one thing, while
   the URI says something else

   <Zakim> noahm, you wanted to talk about clarity of spec language and

   <ht> Here's my recommended text: Extensible Markup Language (XML)
   1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and
   E. Maler, Editors. World Wide Web Consortium, 10 February 1998,
   revised 16 August 2006. The edition cited
   ([23]http://www.w3.org/TR/2006/REC-xml-20060816) was the one current
   at the date of publication of this specification. The latest version
   of XML 1.0 is available at [24]http://www.w3.org/TR/xml/.
   Implementations may follow the edition cited an

     [23] http://www.w3.org/TR/2006/REC-xml-20060816)
     [24] http://www.w3.org/TR/xml/.

   am: reiterates Larry's point about copying text from another spec.
   (ie. vCard) and that this copy came from some dated version
   ... should not copy text, but reference

   lmm: if underlying assumption is that WG stays active, then such
   things don't necessarily matter

   nm: but vague references are a problem separate from that
   ... for any given version of HTML can you answer the question "what
   is conformant"?

   lmm: answer is you read the latest HTML5 spec. and take the latest
   version of every ref'd spec.

   ht: (points to his prose above)

   <ht> d/or any later edition(s); it is implementation-defined which
   editions are supported by an implementation.

   <masinter> [25]http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219

     [25] http://krijnhoetmer.nl/irc-logs/whatwg/20090920#l-219

   ht: this guideline refers to W3C policy of versions vs. editions
   ... W3C has a strict guideline on "what is an edition"
   ... changes between editions are unlikely to invalidate their use

   <Zakim> ht, you wanted to mention edition vs. version

   <DanC_lap> ("W3C has a very strict definition of edition" yeah...
   well... sorta... except we change it sometimes. :-/)

   ht: more you understand about what revisions are possible, easier it
   is to write things such as the above
   ... have to take account of the authors/documents you are referring
   ... in order to do this

   jar: these specs. have contractual nature, and if you can't describe
   the contract, there can be problems
   ... and at least you need clarity
   ... and decide is this what W3C should do?

   <Zakim> jar, you wanted to mention w3c's brand as a standardization
   org, e.g. to us govt

   <Zakim> masinter, you wanted to ask Noah to say what he thinks is

   lmm: if you presume WG continues beyond life of individual spec. and
   that you'll update the spec. quickly

   LM: There's a belief, I think, that efforts to guess in advance the
   kind of changes that will later be needed have not done well.
   Therefore, not worth the time.

   lmm: trying to allow for distributed extensibility and clear
   references is not worth the time
   ... because we have failed in the past
   ... architectural separation between implementation guide describing
   current behaviour vs. long-term specs. that can be referenced
   ... would be a good place to start

   ht: envisaging role of HTML WG being constant maintenance of
   compatibility between browser implementations is a valuable vision
   for the future
   ... and have a longer cycle for the HTML language

   nm: 1 thing HTML WG does is to maintain the language - references
   from that to external specifications should be made clearly, without
   needing to revise the spec.
   ... as a second activity, recognize the documentation of
   implementation interop as being important

   lmm: WHATWG started as "how to build applications using Web
   ... my definition of a platform is a set of interfaces
   ... WHATWG platform has a set of interfaces including JS, HTML etc.
   ... HTML5 combines the def 'n of the HTML language with the def'n of
   the DOM API, Origin interface et al
   ... because the original goal was to define a platform, not one

   ht: should give some thought as to why this might not be seen as an

   <ht> What I said in response to TBL was I would recommend we request
   that the HTML WG consider the matter of dated/updating references,
   suggest that they follow MSM guidelines for W3C Specs, and consider
   "or successors" for IETF refs, on a case-by-case basis

   nm: having an always-on WG prevents a problem where you have a ref'd
   successor spec. which is no longer compatible

   lmm: separate the spec. into two parts - one of which is intended to
   be stable, and which has stable refs
   ... and a second part with makes normative ref to the stable specs.

   <Zakim> jkemp, you wanted to ask would it be appropriate to i) ask
   that WG follows W3C practice on refs to W3 specs and ii) ask a
   question to WG about the clarity of their references,

   JK: As Tim suggested, why can't we go to HTML WG and say "here is
   the W3C policy for referencing W3C specs", and if there's an IETF
   policy for RFCs, etc.

   DC: But there is no W3C policy, there's suggestions from Henry and
   Michael Sperberg-McQueen

   JK: Well then follow that.
   ... Beyond that specific advice, we can make suggestions about
   general approaches.

   <ht> The larger issue is about implementation coherence vs. language
   specification and the impact on that division of the 'always on'

   tbl: challenge the always-on WG - when the spec. goes out it has to
   say more than "this is the list of systems you must support"

   <ht> We should be trying to understand what the best steady-state
   will look like

   scribe missed Tim's point

   lmm: challenges johnk's point about giving the WG specific guidance
   on writing references
   ... and whether that would be useful given the always-on assumption

   nm: we either have to tell the HTML WG something compelling or say
   something compelling to the wider community

   ht: what do we envisage as a viable stead-state situation?
   ... right now we're in anomalous situation, but once we're caught
   up, what should the steady state look like?
   ... along the lines of "we've got this story about implementations
   work, and when they want to change that, because it works so well,
   they'll come to us, and all the impls will change"
   ... so because we have this ongoing process, spec. changes are easy

   tbl: but that doesn't work if you don't signal the kind of changes
   that are likely
   ... implementations already rolled out /won't/ change

   <jar> wondering what the purpose of specs, or this spec in
   particular is. the fact (phenomenon) of a spec is to give a name
   (e.g. HTML5) to a big pile of words. what consequences does this
   have... uses of the spec (in pieces of writings) are various

   nm: variety of refs here, please clarify - eg. difference between
   dated ref and undated URI

   <DanC_lap> (I'm listening for a particularly harmful incidence of
   this "unclear references" issue. Haven't heard one yet.)

   nm: be clear what your policy on references is - to ensure that
   majority of readers come to same conclusion
   ... TAG believes there is value in signaling to community what kinds
   of extensibility are possible
   ... as Tim said, people structure implementations along the axes of
   ... please look for those - is it your intention to support properly
   new versions of unicode, new image types etc. (these are just

   lmm: how we define what Web technology is, is an architectural issue
   for the Web
   ... and we should work out this framework

   ht: consensus about references seems clear
   ... but the larger issue is something unclear, and I largely agree
   with Larry that we should continue to work on that issue

   danc: don't agree with the narrow (references) issue

   ht: XML reference not clear

   danc: relationship to XML is noted elsewhere in the spec.

   (paragraph 2.2.1 XML)

   nm: note danc's objection to the specific references issue

   ACTION ht to draft text on writing references

   <trackbot> Created ACTION-303 - Draft text on writing references [on
   Henry S. Thompson - due 2009-09-30].

   ACTION masinter to draft summary of the larger issue

   <trackbot> Created ACTION-304 - Draft summary of the larger issue
   [on Larry Masinter - due 2009-09-30].


Architecture of Web Applications

   <noahm> scribe: Larry Masinter

   <noahm> scribenick: masinter

   nm: have not committed to form of work in this area: finding, new
   volume, or what

   <noahm> Jonathan's revised version:

     [26] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

   note Jonathan not back from break

   nm: suggest review against previous outline since structure seems
   significantly different

   jk: what is the relationship of these to AWWW? Is this a new volume?

   am: might not be new volume, might be addition

   nm: we tell a story in AWWW about what it means for a URI to connect
   to a resource, Raman's document tells another story about what Ajax
   applications do. I would like to link these stories.
   ... Jonathan's outline looks like a computer science slicing of the
   story and issues.

   ht: the original list was disorganized, we asked JAR to organize it,
   he did, are you saying you don't like his organization?

   nm: JAR's outline... I don't see much about URIs, resources, etc.

   jk: having looked at Device APIs and .... I think there is some
   linking or connection that isn't evident

   tbl: Historically TAG made a mistake of trying to describe web
   services as part of web architecture, but it was different, they're
   different patterns
   ... basically though they're not the same architecture

   tbl, jk: we're documenting something that's completely different

   nm: the use case i have in mind... (showing google maps, zooming
   around): what's going on with URIs? URI i typed in was
   maps.google.com; when I click on it, the client-side application
   will pop up a URI which I can copy, and then put into another
   browser, and get another document which is the map for the point i
   clicked on in the first map
   ... this is an interesting story, all of the URIs are served by

   tbl: when we did the original AWWW it was very spotty, we focused on
   places where people didn't understand. Are there areas here where
   people don't get it?

   nm: most places where people get confused in web applications are
   things like things that Raman wrote about
   ... discussion about permalink meme ...

   am: if I clicked ..??... and did ?? would I get the same URI?

   tbl, nm: generally, if I do the same thing, I get the same URL

   tbl: ... something about interoperability of google maps & yahoo
   maps ...

   nm: a lot of people ask me about designing Ajax apps, and when I
   tell them that, they go "Really?"

   ht: in practice, this is closer to Raman's stuff
   ... you're saying that in practice that's the same, in principle
   ...it could have been done server-side...

   jk: two interesting things: the server is delegating to the client
   the authority to mint URIs that means something. There is a resource
   authority at Google. Resource authorities author the space of URIs

   am: when we start talking about devices, we'll also talk about URIs
   for device state

   nm: (highlights JAR document "Application State" first two bollets
   on "What is state? Where is the state?"

   ht: whether google maps is stateless: you can't tell from the

   nm: if I mail you a URI, you'll get the same document. If there were
   cookies you'd get "session 12? What's that?"

   tbl: it's a browser problem you can't put the permalink URI into the
   address bar
   ... it's a trust issue, the browser should be able to make permalink

   ht: it should always be the case that the address bar tells you what
   you're looking at

   jk: in many cases you can't bookmark things, and user's expect it

   tbl: there's a lot of functionality that (appears to) hangs off the
   address bar (dragging the icon, copying into email)

   nm: going back and forward (demo of google maps) using the browser
   back button, the URI doesn't change but the view changes. This is a
   strange bit of business compared to what we wrote on AWWW
   ... pushback on the idea that these are separate story. These look
   like documents, they should be relevant to AWWW, not be a separate

   am: add stuff to AWWW, not write a separate volume

   nm: we're not much further than we were in june, i'm disappointed,
   where does TAG want to go

   tbl: I think pushing on HTML5 is higher priority than this

   nm: HTML5 might not take up the whole focus
   ... discussion of scheduling ...
   ... discussion of Raman's position ....

   ht: rather than optimizing the table of contents (disagreement that
   what's people are doing) -- we got one more level of detail out of

   lm: i suggest as a concrete action that we review and accept this
   outline as our framework for AWWW volume 2, we accept the action of
   updating AWWW volume 1 which can make reference to volume 2, and we
   push the scheduling of this work to really fire up later

   jk: want to see what the group wants to do on webapis
   ... discussion of scheduling future discussion on this topic ...
   ... I've written a document which explores the examples in 'old
   school' API vs. new WebAPI....
   ... my document may bear on web architecture, jonathan's outline

   nm: propose wrapping this up for now

   lm: let JAR go over his outline when he gets back

HTML issue collection, cont

   ht: XPath and XSLT changes in HTML are issues

   am: yes.

document conformance vs. user agent conformance requirements (#13)

   ht: There are bunch of MUSTs in the document, some of these apply to
   documents and some apply to user agents. wherever there is a MUST
   that applies to documents, there's a corresponding MUST that applies
   to user agents as to what a user agent should do in such cases.
   ... is this a reasonable assumption?

   tbl: specs generally specify protocols. "If you implement according
   to the spec, then you get this benefit", and generally there's a
   link between the implementaiton of the spec and the benefit
   ... most specs leave out the proof that links the "if you implement
   this" to the "you get the following benefit"
   ... when one of the things you have to say is that this works on all
   documents, and works on all extensions, you're right, you can show
   that it's true that when there's a MUST in the document there should
   be an equivalent MUST

   ht: this is a challenging standard to hold the spec to

   tbl: it's never been done before

   ht: my prejudice is: gee it would be so much easier if I had spec A
   and spec B, it would better. In my experience, having these
   intertwined makes it much harder to review. I've worked through 3-4
   examples of this.
   ... example binary values, x=yes or just writing x, x=no or writing
   nothing ...
   ... the specifcations of what you can put in your documents and what
   you do, it is hopelessly entangled, spread out in multiple documents

   nm: it's possible it's spread out for other reasons
   ... what is the reason why it is spread out?

   ht: there is language in chapter 2 section about binary attributes
   which is actually language about agents. When you're looking at
   chapter 9 about user agents is back in chapter 2 that you might
   think you only needed to look at.
   ... one of the things i discovered is that browsers don't strip
   white space from NM tokens. in SGML and XML white space is stripped
   ... simple example is the type attribute link
   ... ... oh i need one that is enumerated ...
   ... halign is either left, right or center. In xhtml you can write
   halign="<newline>left" and that's fine
   ... in sgml it's fine. HTML4 spec says browsers MAY do whitespace
   normalization. HTML5 says they must not.
   ... this is an example where the obvious error recovery is not
   mandated in HTML5 because browsers don't implement this
   ... HTML5 recognizes attributes that have enumerated values

   nm: if you take some of the cases where you're worried about the
   treatment of errors, but here's what I want you to do... I want you
   to establish a clearer convention, to separate out error recovery
   ... would that help?

   ht: it would be a good thing but it would make the spec longer and
   more accessibility

   nm: do you think it's the right direction to look at?

   ht: there's a mixture already .... example where something clarified
   was for user agents and not for documents
   ... discussion was link rel

   <masinter_> "implementor advice" are things that don't belong in the
   authoring spec

   ht: discussion of distinction between specific "user agent" and
   "html consumer", and DOM builder, and position about all HTML
   interpreters should build a DOM
   ... i have this perl script that finds attributes in XML. HTML
   position is everyone should work in terms of the DOM

   nm: is it legitimate... to build a tool, where are the rules for a
   strict parser

   nm, jk: html5 doesn't specify which bits of the parser
   implementation are necessary to build a parser that will only accept
   correct documents?

   scribe: henry looking for example ...

   lm: gives example of error recovery for invalid URI characters
   either signalling an error or generating illegal domain...

   nm: when scripting is involved, the DOM isn't advisory, there has to
   be a DOM
   ... HTML5 is fundamentally a script-enabled version of HTML, but
   because of things like onload, if you're in a script enabled parser,
   if you just load a document and run the script, the only normative
   definition is when there is a DOM

   jk: isn't this similar to XSLT or anogous wher eyou have X? and Y?

   nm: I think the way to think about the HTML dom is that there is no
   Z?, there is no static W?
   ... because you can inject script, can't have a clean model

   lm: is there a place for HTML without document.write?

   ht: it's not enabled in XHTML

   nm: I think this comes from a misapprehension that XHTML would use
   an off-the-shelf ....
   ... discussion of what else would have to be restricted to make a
   simpler spec ...

   tbl: different times when you can use document.write, and some
   places where this causes different problems ...

   nm: innerHTML is much less of a problem

   <timbl> innerHTML()

   nm: some of the approaches we're tempted to recommend for error
   recovery don't work for things like document.write



   nm: is there a kernel of a TAG comment to the working group in an
   area like this? What would it be?

   lm: suggests having IRC chats with HTML-WG / WhatWG

   ht: if we can craft an issue and have a consensus position, we send
   a comment by email, and accept the result
   ... on the other hand, for example, the "always on" point, and how
   much the structure and rhetoric of the spec depends on that, that
   would be a topic for discussion
   ... a call, a joint session in santa clara
   ... IRC has the same drawbacks as a meeting

   ACTION Noah to schedule time at TPAC for joint session with HTML WG

   <trackbot> Created ACTION-305 - Schedule time at TPAC for joint
   session with HTML WG [on Noah Mendelsohn - due 2009-09-30].

   nm: what do we do about 3 on "error handling"

   ht: html5 spec is clear about enumerated values. it is also clear
   that there is a correspondence of properties of dom nodes, what
   happens if i write input something??=banana, i can't find out what
   ... the correspondence between document conformance and error
   recovery isn't not clear
   ... having told that detailed story, the higher level story is ...
   what about a question of the form, "please make explicit connections
   between document conformance and error recovery which user agents"

   nm: the form of our feedback would be that someone would draft

   ht: i just asked on public-html-comments, if the answer was there
   was a bug


   <ht> s/isn't not clear/isn't clear/

   <ht> s/agents"/agents must carry out for non-conformant documents"/

   nm: tasking to frame an issue is better

discussion of work on webapis

   review of JK document


     [27] http://www.w3.org/2001/tag/2009/09/apis-on-the-web.html

   lm: i see the cases, think i understand the examples enough, what is
   the differences

   ht: what is window.navigator

   jk: took this example out of geolocation spec

   nm: the operating system decides when it has interesting information

   ht: example should include numeric parameter of amount of rainfall
   ... discussion of example and whether there is two or one web page
   ... discussion of cars as rain guages ...

   <timbl> meteo = rdf.load(NadiasMeteo); rain=meto.the(NadiasSensor,

   ht: URIs being minted by client ... discussion of resources and URIs
   in the two examples ...

   <timbl> or kb.looup(NadiasSensor); rain=meto.the(NadiasSensor,

   nm: how am I going to implement this?
   ... if you're using web infrastructure use the terminology of web
   ... geolocation draft ... does the TAG want to make a recommendation
   about that draft on the use of URIs for this?

   ht: Why does it make sense to think that any device that have state
   that is useful for web applications should give IP addresses to

   lm: could we suggest that, in the design pattern where client sends
   request to server, gets back content which interacts with local
   state, uses that state to customize information, and then presents
   information to the user based on state, that the information used
   (or the state used) should be serializable?
   ... trying to get back to the permalink idea
   ... or that google maps & yahoo maps might interoperate?
   ... trying to see if there's a distinction between "geographic
   location" and accelerometer

   <jkemp> [28]http://phonegap.pbworks.com/JavaScript-API shows an
   accelerometer JS API, for example

     [28] http://phonegap.pbworks.com/JavaScript-API

   nm: maybe standardizing way temperature is embedded in a URI or
   query string ... seems funny
   ... does this need to be standardized?
   ... discouraged metadata in URIs? Lattitude & Logitude

   am: what about this case?

   nm: what resolution? What privacy and security issues?

   <timbl> [29]http://www.w3.org/2009/09/Nadia/meteo#sensor

     [29] http://www.w3.org/2009/09/Nadia/meteo#sensor

   lm: question about extensibility of GeoLocation to civic location

   nm: this is following to the letter the guidelines for javascript

   lm: where are the guidelines for writing extensible API
   ... discussion of whether TAG should give guidelines ....



   nm: what are our priorities? suggestion was made that it was new.
   not like device stuff is first example? Should the tag be looking at
   or saying interesting things about this?

   am: what would we update in the architecture?

   <jkemp> * Scripted APIs, as currently specified are possibly not
   self-describing (and one might not be able to "follow one's nose" to
   access data exposed in this way)

   <jkemp> * There is no HTTP-like "uniform interface" yet described
   for scripted APIs

   <jkemp> * The impact of state on the presence and usage of an API
   (for example, how DOM events can affect the results of an API call).

   <jkemp> * URIs to resources exposed via scripted APIs (especially in
   the case that a URI does not exist for such a resource)

   jk: these came from meeting w/Ashok



   privacy & security in APIs?

   scribe: discussion of geopriv, policy languages, etc...
   ... whether services that suck your conact list...

   am: who is going to enforce this?

   dc: if they share the info and get caught they would be busted

   am: whoever has access is somehow identified

   lm: belief is that it is one bit "public or not"

   jk: EU laws, indicate the user agreed to some action
   ... discussion of 'evil' bit ...
   ... we tried to use P3P, didn't gain any adoption or consensus

   tbl: are they all armchair programmers?

   jk: design patterns for extensibility good tag topic, not restricted
   to APIs ..
   ... there are some minor issues here, then there are some other
   issues that have broader context....
   ... other issues that are broader

   nm: two statements: (1) there are a bunch of people doing APIs in
   javascript, mostly don't need the tag's help
   ... (2) the tag is here to areas where things are not coming out as
   well as it should, and if the TAG gets involved
   ... I don't hear people popping up and saying "that's not an API"

   jk: many people are proposing a way of doing versioning

   nm: there are many people who are doing it already

   tbl: versioning is icing on the cake, the main problem is that there
   is no modules
   ... if you're using google maps and yahoo maps the two aren't

   dc: panel discussion, as it was breaking up.... can we have the same
   thing for loading modules?

   nm: if we made a blog posting, that this remains a problem, this
   really is troubling?

   lm: ECMA & W3C at TPAC question?

   is there a meeting planned?

   sorry, TC39 and HTML

   if we're discussing modularity and APIs

   ht: this is one of the 5 unknown problems in Computer Science

   tbl: various pieces of software have to do the loading

   danc: who makes up package names? debian developer community is
   'always on'

   jar: replacing short names with URIs

   ht: , app.get(banana) changes from week to week

   dc: debian community is mutually trusting

   tbl: they should be using URIs, for distributed extensibility

   jar: necessary level of indirection because of the architecture

   tbl: search path, can search things in sequence

   <ht> s/Computer Science/practical Computer Science/

   <ht> s/unknown/unsolved/

   lm: concern about apis using enumerations and characterizing which
   apis are supported by which category the device or service is vs.
   characteristics or features...

   tbl: what about a thing which is a 'calendar' but there are 17
   calendars and choose between whether it's a calendar and or a phone

   nm: mixins

   jar: we have a language for describing things, it's OWL
   ... this technology covers a large space of the problem

   dc: compare this to the user agent header

   lm: User Agent is an example of where the web community didn't get
   it right

   dc: user agent field allows you to know about 'bugs'

   nm: gets device characterization

   dc: what gets widely deployed are databases that match user agent
   fields to database

   nm: please give me a short thing

   dc: user agent field for iPhone is long

   <noahm> Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en)
   AppleWebKit/420+ (KHTML, like Gecko)

   <noahm> Version/3.0 Mobile/1A543a Safari/419.3

   dc: lists all the features because user agent

   jar: is this part of a sql query?

   action larry to work with JK and AM to update Web APplication
   architecture outline based on discussions at TAG meetings

   <trackbot> Created ACTION-306 - Work with JK and AM to update Web
   APplication architecture outline based on discussions at TAG
   meetings [on Larry Masinter - due 2009-09-30].

   <noahm> CLOSE ACTION-300

   <trackbot> ACTION-300 Prepare draft on device APIs closed

wrap up for the day (agenda review)

   action danc to raise issue of work items moving between W3C working
   groups and also with IETF

   <trackbot> Created ACTION-307 - Raise issue of work items moving
   between W3C working groups and also with IETF [on Dan Connolly - due

   <noahm> Closing action 273

   <noahm> ACTION-295 Due 25 Sep

   <trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
   comments on last call and report to the TAG due date now 25 Sep

   <noahm> ACTION-301 Due 24 sep

   <trackbot> ACTION-301 Review websocket protocol/api motivation and
   brief TAG at Sep ftf due date now 24 sep

Summary of Action Items

   [End of minutes]

    Minutes formatted by David Booth's [32]scribe.perl version 1.134
    ([33]CVS log)
    $Date: 2009/10/12 17:21:32 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [33] http://dev.w3.org/cvsweb/2002/scribe/


      [1] http://www.w3.org/

                               - DRAFT -

                            TAG f2f, day 2

24 Sep 2009


      [2] http://www.w3.org/2001/tag/2009/09/23-agenda.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/09/24-tagmem-irc


          Tim Berners-Lee, Dan Connolly, John Kemp, (in part), Ashok
          Malhotra, Larry Masinter, Noah Mendelsohn, Jonathan Rees,
          Henry S. Thompson, ( Lisa Dusseault and Mark Nottingham by
          invitation, in part, by telephone)

          T. V. Raman

          Noah Mendelsohn

          Henry S. Thompson (morning), Dan Connolly (afternoon)


     * [4]Topics
         1. [5]Metadata
         2. [6]Content-type sniffing
         3. [7]Web Application Architecture
         4. [8]Naming Schemes
     * [9]Summary of Action Items


     [10] http://www.w3.org/2001/tag/2009/09/23-agenda.html#metadata

   [Two updates for agenda: sessions likely on Javascript security and
   Distributed extensibility]

   AM: Hoping for drafts from Mark N. and Eren to start from. New draft
   has arrived from Mark N., "?? well-known URIs" [ref?]. Apparently a
   replacement for the site-meta draft, quite short. JAR likes LM's
   suggestion that we work on a whitepaper surveying the state of play
   wrt metadata

   <DanC_lap> (I didn't get the impression that the well-known URIs
   draft was a replacement for site-meta)

   <noahm> Well, Dan, the title certainly makes it sound different. I
   haven't read it yet. Do we have a link?

   JAR: I took an action [ACTION-282] to draft a document in this area,
   which got closed for lack of action but I'm willing to resurrect
   this because I expect to have some time available not just formats
   and transport, but also life-cycle

   <DanC_lap> action-281?

   <trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
   of link header draft, report to TAG, warn us of problems (ISSUE-62)
   -- due 2009-08-01 -- OPEN

   <trackbot> [11]http://www.w3.org/2001/tag/group/track/actions/281

     [11] http://www.w3.org/2001/tag/group/track/actions/281

   <noahm> ACTION-281 Due 30 Oct

   <trackbot> ACTION-281 Keep an eye on progress of link header draft,
   report to TAG, warn us of problems (ISSUE-62) due date now 30 Oct

   <noahm> action-282?

   <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
   metadata architecture. -- due 2009-08-31 -- CLOSED

   <trackbot> [12]http://www.w3.org/2001/tag/group/track/actions/282

     [12] http://www.w3.org/2001/tag/group/track/actions/282

   <noahm> Action 282 was reopened by editing the record, now has note
   stating: Reopened at Sept 2009 F2F because Jonathan says he is doing
   a draft after all. Expected to cover both access and formats (and
   maybe more).

   <noahm> The action numbered 282 is now due Oct 13

   JR: Next step will be a draft

   LM: I'll be happy to contribute effort

   <DanC_lap> action-282?

   <trackbot> ACTION-282 -- Jonathan Rees to draft a finding on
   metadata architecture. -- due 2009-10-13 -- OPEN

   <trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/282

     [13] http://www.w3.org/2001/tag/group/track/actions/282

Content-type sniffing:

     [14] http://www.w3.org/2001/tag/2009/09/23-agenda.html#sniffing

   <noahm> Preparing for call with Mark Nottingham and Lisa Dusseault,
   which will be in about 30 mins

   DC: My starting point is the example of serving XML as text/plain,
   because you want to show the angle brackets but if you have various
   magic strings near the beginning, browsers will treat it as HTML
   anyway. Ian Hickson fought this for 10 years, then gave up and wrote
   a description of it (sniffing) into the HTML 5 spec. This was
   queried as it wasn't HTML, but rather HTTP. So Adam Barth took the
   relevant bit out and wrote it up as an Internet Draft. Not clear
   where this draft is heading. Both groups (HTML WG and HTTP bis WG)
   have closed their issues on this

   NM: What are Lisa and Mark's roles?

   DC: Mark is chair of HTTP bis WG, Lisa is relevant IETF Area
   Director. Should we leave the unsatisfactory status quo in place, or
   try to expose the unsatisfactory nature of the resolution?

   LM: This is a kind of error-recovery issue. Browsers are trying to
   accommodate users who have tried to publish HTML, but are getting it
   served as text/plain, or who are publishing images with the wrong
   mime type, typically through no fault of their own

   JR: But it's an odd kind of error -- it's undetectable. I've been
   burned by precisely DC's example

   NM: Example here:

     [15] http://www.hoahdemo.com/rte/Metadata/broken_text.xml

   <noahm> (I may or may not leave that content up there for the long
   term...it's a page I put together mostly for my own use, but it's
   fine for everyone to try it.)

   LM: Hixie is just documenting a compromise position wrt what the
   browsers are doing already

   <DanC_lap> (Fielding gives a colorful history of the sniffing issue.
   I wonder whether to bring it up orally.
   l )


   HT: My understanding is a bit different from what Dan said. I
   started out believing we had a problem. I said in my notes
   "shouldn't the fact that Adam Barth's draft is incompatible with RFC
   2616" at least be acknowledged in the HTML spec. But, if I "follow
   my nose" from HTML issue 5 I get to this message



   <DanC_lap> (I don't think 5 is the right number)

   <DanC_lap> relevant HTML WG issue is

     [18] http://www.w3.org/html/wg/tracker/issues/28

   HT: In that, Mark Nottingham says that sniffing does not conflict
   with RFC 2616. That issue is closed, but it's not quite clear from
   Tracker what logic was used to close it.

   DC: We discussed this before, and you agreed.

   <ht> [19]http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155

     [19] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155

   HT: For HTTPBis, it's issue 155, which appears to say that "provided
   user controls are in place, sniffing will be allowed."

   <DanC_lap> "HST: OK, thanks for clarifying, I understand better now"
   -- [20]http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html

     [20] http://www.w3.org/2001/tag/2009/09/10-tagmem-minutes.html

   HT: Seems to contradict Dan's saying that a user surveying pertinent
   specs won't discover the problem. I think if HTTPbis goes this way,
   we'll have to revisit the authoritative metadata finding.

   DC: Would like to see what Henry is referring to.

   HT: From HTTP bis issue 155:

     HT: The language should be updated to reflect this reality,
     without unduly encouraging the use of sniffing except where
     necessary. Ideally, it will be done in such a way that:

     * Does not require sniffing for all uses of HTTP (i.e., a
     particular implementation and/or user can "opt in" to the use of a
     sniffing algorithm), since this is most commonly a problem for the
     browser case, and

     * Specifically allows a user and/or content provider to opt out of
     the use of sniffing in a particular interaction, and

     * Promotes interoperability (i.e., if two implementations sniff,
     they will do so in the same way).

   DC: But they didn't do that.

   DC: Looking at ticket 155. . .

   <noahm> Note proposal 8 weeks ago:

   <noahm> Proposal from HTTP WG meeting: remove the sentence:

   <noahm> "Note that neither the interpretation of the data type of a
   message nor the behaviors caused by it are defined by HTTP; this
   potentially includes examination of the content to override any
   indicated type ("sniffing")."

   NM: It appear that the HTTP bis WG has in fact done that deletion


     [21] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07

   NM: looking at section 3.2.1 in current draft having difficulties

   ion-3.2.1 perhaps?


   <DanC_lap> "Note that neither the interpretation of the data type of
   a message nor the behaviors caused by it are defined by HTTP; this
   potentially includes examination of the content to override any
   indicated type ("sniffing")."

   DC: Not clear if this has been removed

   <Zakim> noahm, you wanted to ask about functions vs. specs

   NM: Two issues for the TAG:
   ... 1) How strong do we feel about this?
   ... 2) What does and should the specs say?

   <DanC_lap> (so indeed, it'll be handy to have Mark help us navigate
   their issues list and tell us what the status of this issue is.)

   NM: We all agree that in the real world this shouldn't be necessary.
   But how can the TAG be helpful given the exigencies of the real
   world where it is?

   DC: I think the Authoritative Metadata should be revised. RF said
   "over my dead body" wrt that proposal some years ago

   <noahm> [23]http://www.w3.org/2001/tag/doc/mime-respect

     [23] http://www.w3.org/2001/tag/doc/mime-respect

   HT: No, I remember the exchange: the TAG's position is (was) don't
   do that. period.

   TBL: The architectural rule is "don't do it"

   TBL: That's still the right architectural decision, and when it's
   not observed there's damage

   <Zakim> timbl, you wanted to wonder about a practical solution being
   to involve the user and keep a per-site kludge list like for "bad"

   TBL: You could address this by browsers have a way to record user
   preference to see some 'text/plain' as appl/xml then you could
   generalise to "should I always treat text/plain from [this site] as

   LM: But there's no point in writing a spec. if browser makers won't
   attend -- true or false?. I haven't been able to rebut this

   TBL: For example, wrt certificates, we argued for years to improve
   things, and they finally moved. We could find out what the facts
   are, and if we made a proposal which helped the browsers, they might
   find it helpful

   LM: So, we could say we don't want W3C to publish a spec. which
   encourages sniffing

   DC: Not without showing a way out of the current local minimum.
   Could we build an extension which illustrated TBL's suggestion?

   HST: Depends on whether there's a hook in Mozilla for this case?

   DC: Or we could ask for a hook -- that's easier than asking for a
   change in the UI

   [Lisa Dusseault and Mark Nottingham join the meeting via the 'phone]

   NM: Thanks for joining us to discuss sniffing. Our starting point is
   that architecturally sniffing is bad, but maybe there's a case for
   at least documenting the workarounds for the practical difficulties
   caused by misleading media types

   MN: Our issue 155 is about sniffing

   MN: we came to consensus that HTTP should get out of the business of
   ruling out sniffing and just say that Content-type: is for users to
   indicate what they think, but not say "don't sniff". So don't
   encourage it, and certainly not require it, but stop making it
   non-conformant to do it. Then there can be a draft such as Adam
   Barth's. There was discussion about including something in the HTTP
   bis draft itself on how to sniff, but we didn't go there

   NM: Stable now? Anyone pushing back?

   HT: The last decision we see recorded on your issue 155 seemed to be
   to remove the text.

   MN: I believe it's stable

   HST: But you appear to have removed the spec. which allows it

   <DanC_lap> "nothing in the HTTP spec that says you can't". so the
   spec is silent on it.

   MN: But there's nothing which rules it out -- we pulled that text
   because some people thought it went too far towards encouraging

   LD: We've told Adam Barth that to take his work forward, he would
   need to either: 1) Form a WG around this topic to take it forward;
   2) Get it encorporated in the HTTP bis draft (although MN has
   declined to do this for the time being); 3) Get an Area Director to
   sponsor its publication as an Informational [RFC]

   NM: Could HTML 5 reference an Informational normatively?

   LD: That's a complex question of how W3C and IETF processes
   interact. . .

   LM: We're still dancing around the question of what the right
   behaviour is wrt the fact that deployed software does error recovery
   which is heading for being embedded in standards. I'd like to avoid
   having this stuff ping-pong between W3C and IETF

   TBL: I put myself on the queue to say I would like a name for a
   clean HTTP. If there's sniffing in it, call it something other than
   HTTP -- HTTP_unclean. We should continue to promote the clean

   NM: Do you want the difference in-band in the requests?

   TBL: No

   DC: Wrt ping-pong, when one org's group starts overlapping with the
   other's, there has to be interaction at least we got the overlap
   area broken out into its own draft but the HTTP bis WG has decided
   to be silent about this. So the question has become whether to
   reabsorb the AB draft, or sight it as Informational

   LD: I don't know about your process, but we have an explicit
   mechanism in our process for referencing an Informational

   DC: You can do it unless someone complains

   LM: It's like referencing a Note -- can you do that normatively?

   HST: Yes

   DC: Unless someone complains and it's upheld

   <noahm> [John Kemp arrives]

   MN: We were asked to confirm that HTTP bis doesn't conflict with
   sniffing, and we decided to accept that. At the moment we're waiting
   to see where AB's draft goes. It's not strictly speaking in our
   charter to incorporate it. But we could revisit that if we needed to
   -- might require agreement from Lisa. Wrt HTTP_Unclean, we should
   come up with a browser profile for HTTP usage, which said "use [this
   URI cleanup] and [this sniffing] specs in this way". So it would be
   a separate profile, rather than forking the HTTP spec itself

   TBL: So documenting a set of willful violations would be a good

   MN: We're coming to the conclusion that it's not a violation

   <Zakim> masinter, you wanted to ask whether there have been other
   cases where stuff has bounced over the boundary between application
   semantics and protocol semantics

   MN: Remember WSI -- they built profiles by combining other specs --
   HTML 5 should be a spec. for a language, and a story about browser
   behaviour should be told elsewhere, in a similar way to the WSI

   LM: HTTP defines the protocol and what it means, and the browser
   spec. specifies how it uses the protocol, with some wrapping/post-
   and pre- processing. E.g. "HTTP says this is 'text/plain', but in
   such-and-such a case, you should ignore that and use ... instead" is
   there another example of this?

   MN: Content-type and Content-encoding

   LM: That's for browsers -- any other applications -- using SIP (?)
   for instance?

   MN: Not aware of any. . .

   LD: There is some precedence for one IETF spec. saying "MUST" which
   overrides a "MUST NOT" in another spec.

   LM: What about CRLF in mime vs in HTTP -- HTTP overrode that to
   match current practice

   MN: Yes, header length and header wrapping minutiae -- HTTP is not a
   mime protocol but its a mime-like protocol. . . .

   HT: Part of the TAG history, is that when we last discussed this
   issue, in the context of our "Authoritative Metdata" findin", we
   decided not to change it. The finding thus continues to say that
   authoritative metadata is binding. We believe that finding author
   [editor?] Roy Fielding's view is that changing this would be "over
   his dead body". Seems like people are feeling "worn down". I think I
   know what Roy would say. But...

   MN: Hard to answer

   <Zakim> lisa, you wanted to try to sum up current consensus

   MN: We did pull that text we talked about, because it was too
   explilcit -- "not in our spec.", what they do in their own specs is
   on their back

   LD: We are doing more reality-based protocol design, less policing.
   Maybe this means lots of health warnings. So e.g. Geopriv clients
   shouldn't accept 'text/plain'....

   MN: The concerns haven't been so much around purity, as around the
   viability of this as a long-term solution

   <timbl> Go not gently into that good night -- but fight, fight
   against the dying of the light. [From Dylan Thomas Do not go gentle
   into that good night]

   LD: Having a real document setting out how it can be done reasonably
   well changed the debate

   TBL: But it's harmful, it makes things break -- we can't forget
   that. If you intentionally serve some XHTML as text/plain, as an
   example, it's just broken if that isn't displayed as such

   <noahm> Example that breaks browsers that sniff:

     [24] http://www.noahdemo.com/rte/Metadata/broken_text.xml

   TBL: there are also potential security holes. It makes specs more
   complicated. It's important to describe the system which works as
   the architecture specifies

   <noahm> The example is meant to illustrate a bug reporting system,
   in which the desire is to show the user buggy XML as text/plain.

   TBL: and separate out the accommodations. I'd like a browser to
   prompt me before using sniffing to decide how to render, so I can
   decide whether I want this done for this site

   NM: Positive steps?

   TBL: I like the idea of a browser profile -- put all the kludges and
   fixups there. But I don't want HTTP to include a sniffing section

   NM: So the current HTTP spec. is OK by being silent?

   TBL: I'd prefer it to point out the damage the comes from sniffing,
   but also reference the AB draft

   <HST:> HST thinks "Your foot, your gun, your bullet"

   LD: Yes, we are trying to work that way

   NM: If the TAG were to undertake to produce a finding or a REC of
   the form "Here are guidelines for using internet protocols and
   formats such as HTTP and media types and ... in a style which meets
   the needs of the browsing community" which would either explain how
   or point to e.g. AB's draft on how to do this, and point out the
   pros and cons is that what you had in mind TBL, and should the TAG
   do it?

   <masinter> I like this: MIME types, URIs, HTTP protocol, maybe other

   TBL: I think it should happen elsewhere

   NM: More to do with LD and MN?

   HST: No

   NM: MN and LD, anything more?

   LD: Better coming from the community

   NM: Thank you very much for joining us

   <lisa> thanks that was useful to me too

   [LD and MN leave the call]

   <DanC_lap> some clues on mozilla hooks re media types:


   [adjourned for break until 1105]


   NM: Agenda discussion -- more on sniffing, or. . .

   DC: Sniffing, maybe. How to clean up metadata:. List of legacy
   sites. Treat as text/plain option (extension). Opera already has a
   list of sites which it patches CSS for or some such. There is a FF
   extension which allows JSON to be viewed instead of 'Save As...' so
   maybe there could be a generic show as text/plain extension

   NM: What about an 'i really mean it' media type header?

   HST: Microsoft tried it, didn't they?

   TBL: I thought that would have been fine, yes

   HST: How does the user indicate to turn that on

   TBL: It's turned on by default for new sites

   NM: [an untarring example?]

   <masinter> example was whether web hosting sites provision servers
   by installing (untarring) old blog software that had bug that images
   were served as text/plain

   JK: Suppose the user maliciously serves javascript as text/plain,
   Adam Barth says this is a security hole

   DC: This hole requires sniffing for the privilege escalation to

   NM: But if you had a switch that said "don't do that", there's not

   DC: [draws and speaks to a timeline]

   HST: Does or does not AB's draft mandate leaving explicit text/plain

   [WG reviews the AB draft:

     [26] http://tools.ietf.org/html/draft-abarth-mime-sniff-01

   JK: OK, explicit text/plain must be left alone

   DC: So that's FF behaviour, not IE

   <jkemp> (section 3 of AB draft, Web Pages, step 3)

   NM: What about images served as text/plain

   HST: I think that's caught as binary by the algorithm

   [WG goes back to the draft]

   TBL: It's not the format that's safe/unsafe, it's what you do with
   it. Safari is confused about this. I think this is worth saying

   LM: I can see no motivation for ever sniffing postscript or pdf. I
   believe that Adobe folks thought this wasn't important to sniff if
   it did happen. What's the use case? Or for XML?

   TBL: Because stuff is served with no Content-Type?

   NM: It's plausible to me that there's PDF being served with no

   DC: The goal is to get to the point where if you mislabel your
   content you will have to fix it. The new idea is to bake the list of
   sites which need to be sniffed into the browsers

   LM: If for the only things mislabelled at a site wouldn't give any
   clear benefit to users if they were sniffed, then they don't need to
   be on the list

   HST: How's it going for IE8 wrt conformance opt-out?

   DC: I understand this includes a baked-in list of known-need-fixing

   TBL: I support this

   HST: It's an important precedent for shipping strict and allowing
   exceptions to be logged

   <Zakim> timbl, you wanted to note that the browser can generate the
   lists before it starts using it, if you allow a bit of feedback.

   <masinter> i think we should push back on sniffing, that there needs
   to be a clear user benefit to someone for sniffing, that it isn't
   enough that there's some content that browsers currently sniff, it
   actually has to be shown to be important

   TBL: The list of legacy sites can grow in a distributed fashion

   DC: Lots of cleverness possible here

   <masinter> I don't think we should rely on the wisdom of browser
   implementors to have actually done the thing that is best for their
   users, some browser "error correction" behavior might have been

   NM: What about the "i mean it" flag?

   DC: We don't know what the facts are. . .

   NM: DC, next step?

   DC: Ask Microsoft to do this?. Seems to me this would work

   LM: I have come to wanting to push back on the sniffing draft as
   being speculative that is, codifying what browsers do, minus
   escalation. A lot of these may have been speculative patchup by a
   browser implementor but assuming that all of these are actually in
   users' interests is dubious. Maybe they were just generalising
   unnecessarily. We need to see clear user benefit before we endorse
   this, line by line

   HST: Isn't sniffing PDF when you have the 'unknown type' case a user

   LM: No -- I think unknown should always take you to
   application/octet-stream, and users have to choose to ignore or
   save. Then it's their choice to try it as PDF

   NM: Maybe it would be good to find out if the current algorithm is
   desirable wrt user benefit, but independently of that, documenting
   what current practice is is useful

   <masinter> i am opposed to mandating (rather than describing)
   behavior that has no clear user advantage, especially where that
   behavior is at odds with other specifications

   NM: What the TAG should be doing is documenting what is or isn't
   good about that, and how it's architecturally good or not

   LM: I think the clear priority of the [HTML] WG is to match reality,
   and that's not what users need, but what browsers do there's some
   correlation, but it's not perfect the pressure to ship is sometimes

   <jkemp> if there is the opportunity to do something clever without
   negatively impacting security, I think we should leave that
   possibility open

   NM: Disruption to users is presumably high on the WG's list, we have
   to be careful

   <masinter> i wasn't arguing this on "architectural purity" grounds,
   but on "must have clear user benefit"

   HST: Note that contrary to what LM implied, the AB draft goes beyond
   just documenting what browsers do, by ruling out priviledge
   escalation. . .

   DC: LM actually acknowledged that security concerns had led to some

   HST: OK, sorry, missed that

   TBL: There have been strong statements from the HTML WG that
   browsers that don't do sniffing suffer in the marketplace maybe
   everybody has converged, so there can't be any hard evidence

   <Zakim> masinter, you wanted to say that NM was arguing against a

   TBL: by maybe it can have gone to far

   LM: I'm not saying that some sniffing doesn't have user benefit but
   that not all of the draft stands up to that test. For example
   sniffing postscript is pointless, given that most browsers won't do
   anything with the information anyway

   <DanC_lap> (timbl re "treat as text/plain", fyi, LeeF just told me
   about [27]http://www.spasche.net/openinbrowser/ which seems to
   support that.)

     [27] http://www.spasche.net/openinbrowser/

   NM: But that would compromise vendors ability to say "This version
   is backwards compatible with last years", full stop. and not by

   <DanC_lap> ("This extension won't be useful anymore once Bug 57342
   and Bug 258012 have been implemented.")

   NM: what next?

   DC: 1.5 hours on Friday to write a blog post about Hixie's draft?

   <noahm> close ACTION-257

   <trackbot> ACTION-257 invite Mark Not or Lisa D to revisit progress
   in IETF/HTML liaison on content sniffing closed

   DC: What about updating authoritative metadata?

   HT: Shouldn't that wait on seeing what httpBis says?

   HST: I heard TBL say things which suggest we should push back on the
   current state of the HTTP bis draft. Because it doesn't say "Don't
   do that: sniffing breaks things"

   NM: [ proposes update to Self-describing Web, because it assumes
   Authoritative Metadata]

   DC: +1

   <DanC_lap> (what Noah is saying is what I have in mind. We don't
   change the architecture, but we do FYI: widely deployed practice
   diverges in the following ways...)

   <noahm> Right. I would change SDW to say: the chain of
   specifications holds only insofar as you act on the authoritative
   metadata. That said, if sniffing goes ahead, users should be warned
   that they may sometimes be shown information inferred from sniffing,
   that such information is not in all cases traceable to the SDW chain
   of specs, and thus is to some degree suspect.

   DC: I don't think we should change the fundamental conclusion of
   Auth. Metadata, but we should clarify that the world hasn't agreed

   <jkemp> here's a diff of the changes to HTTPbis for sniffing:


   NM: I think we can be confident that some justification for browsers
   continuing to sniff will be forthcoming so let's go ahead and
   explore updating those two findings

   <scribe> ACTION: John to propose updates to Authoritative Metadata
   and Self-Describing Web to acknowledge the reality of sniffing, due
   2009-10-20 [recorded in

     [29] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01

   <trackbot> Created ACTION-308 - Propose updates to Authoritative
   Metadata and Self-Describing Web to acknowledge the reality of
   sniffing, due 2009-10-20 [on John Kemp - due 2009-10-01].

   HST: Are we happy with the state of the HTTP bis draft wrt sniffing?

   <DanC_lap> jkemp, are you confident that diff is after the WG
   decision that mnot informed us of?

   [pause to find authoritative draft of IETF bis part 3]


     [30] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-07

   NM: Do we believe they are still planning further changes to the
   draft at that URI, or is it likely to come out in the current form?

   HT: Seems like more changes coming.

   NM: OK, then I think it's premature for us to plan a response.



   <ht> That URI does identify the text after the edit we have been
   discussing, to remove the final paragraph of 3.2.1

   <DanC_lap> (remind me where the remaining sniffing text is? it
   doesn't use the word "sniff")

   JK: Another important change, is that an 'if-and-only-if' was
   removed from the no-content-type case

   trackbot, status?

   <scribe> ACTION: Henry S. to bring back proposed TAG pushback on
   sniffing and HTTP bis draft
   -httpbis/latest/p3-payload.html, or his recommendation that we leave
   it alone [recorded in


     [33] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02

   <trackbot> Created ACTION-309 - HST to bring back proposed TAG
   pushback on sniffing and HTTP bis draft
   -httpbis/latest/p3-payload.html, or his recommendation that we leave
   it alone [on Henry S. Thompson - due 2009-10-01].


   [adjourned until 1345 for lunch]


   <DanC_lap> js sec, plenary, writing session, what got booted...

   <DanC_lap> again, on ECMA foo: Archived-At:

     [35] http://www.w3.org/mid/4ABB67E8.4080408@intertwingly.net%3E

   <noahm> ACTION: Noah to check with Sam Ruby on ECMA/W3C activities
   at TPAC [recorded in

     [36] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03

   <trackbot> Created ACTION-310 - Check with Sam Ruby on ECMA/W3C
   activities at TPAC [on Noah Mendelsohn - due 2009-10-01].

   <jar> [37]http://www.w3.org/TR/WebIDL/

     [37] http://www.w3.org/TR/WebIDL/

   <DanC_lap> also note work on a WebIDL checker


   <DanC_lap> scribenick: DanC_lap

   agenda order is 1, 6, 2

   agenda order is 1, 3, 6, 2

Web Application Architecture


   <trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
   Application ( [39]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
   ) outline with as many sentences as he can -- due 2009-09-15 -- OPEN

     [39] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

   <trackbot> [40]http://www.w3.org/2001/tag/group/track/actions/284

     [40] http://www.w3.org/2001/tag/group/track/actions/284

   updated outline:

     [41] http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

   discussion of level of interest, expertise, etc. ...

   <masinter> +q to look for areas where this isn't just "good CS",
   i.e., things that make this web architecture vs. architecture

   discussion of parallels with work on WebArch v1

   <Zakim> masinter, you wanted to look for areas where this isn't just
   "good CS", i.e., things that make this web architecture vs.

   JAR: I touched on that in "Goals: Network effects, overall user
   experience (not just at your site), robustness, enabling automation.
   You should read this document if and only if you care about these

   LMM: the 2 I can think of are: relationship beetween the
   static/document web and the semantic web and the application web the
   google maps URI for something was a good example. [of ...? scribe
   might have missed a bit]
   ... 2) trust. in AWWW [webarch v1] there's discussion of authority
   and ownership, which is a sort of trust model...

   HST concerned he's missed some of the scribe log -- RRSAgent wasn't
   watching -- we seem to drop into the middle of the web sockets topic
   http://jkemp.net/tag/hybi.html -- DanC, do you have local copy?

   <masinter> if I'm running web sockets and i'm talking to someone i
   know is running web sockets, that's the simplest method, we'll just
   talk websockets

   LMM: e.g. it might be used to get stock quotes, but not by a RESTful
   GET on a stock price resource.

   <masinter> but if you're over port 80 and you're in a hotel and it
   is noon, port 80 request might get intercepted and the hotel ask you
   to log in and pay for another day's internet access

   LMM: no links, bookmarks, etc. ... like web services

   HT asked for a motivating example in order to get context for [which
   question? scribe lost the train of thought]. We go back to slide
   1... IM, multiplayer gaming... TBL suggests collaborative

   HT: years ago Richard Tobin and I did [42]this sort of thing in a
   RESTful way... with URIs for the interesting things...

     [42] http://www.hcrc.ed.ac.uk/~ht/hotknit/index.html

   JK: yes, people do these things over HTTP, in a RESTful way, but
   they run into issues... proxies buffer multiple events into one
   response another: the 2 connection limit from RFC2616 [which LMM
   points out has been relaxed in HTTPbis]...

   LMM: the reasons for that 2 connection limit are historical; it's
   been replaced by "do the right thing"

   JK: 3) the UPGRADE header is not passed along by proxies

   DC: huh? how did UPGRADE come up in a list of issues re RESTful

   <Zakim> DanC_lap, you wanted to ask LMM more about IETF status of
   hybi wiki and to note the presentation I saw at the SFO IETF
   convinced me you need 2 HTTP connections

   HT: Why do Bayeux and BOSH need to use Upgrade: ?

   DC: I saw a presentation on several of these. One was from Jabber
   XMPP suggested best design is two connections.

   NM: To avoid deadlock?

   DC: Maybe, or might have been Javascript issues. Anyway, Websockets
   is only one connection.. Larry, you said are we aware of hybi, and
   we said yet. Then you said something about working group. Is there a
   working group?

   LM: There was BOF and discussion of proposed charter

   DC: on hybi... when is it likely to be an IETF WG?

   LMM: at the Nov IETF meeting in Hiroshima... the charter wrangling
   issue is whether a "2 browsers" constraint should go in the charter
   as to why this shold be a WG... it's to get the middle of the
   network.. proxies... cisco... to acknowledge this as legitimate to
   address reliability issues



   NM: what I wonder if what the TAG should do is... consider this

   <jkemp> [44]http://trac.tools.ietf.org/bof/trac/wiki/HyBi a good

     [44] http://trac.tools.ietf.org/bof/trac/wiki/HyBi

   NM: [something about self description or not. scribe is lost.] media
   types... following links... content negotiation to use same URI for
   RDF and HTML representations so that's motivation for traditional
   RESTful access...

   <jkemp> Note:

     <jkemp> A sentiment has been expressed that perhaps the HyBi group
     should not try to pick a specific "winner" with regards to
     selecting a single bidirectional protocol. Instead the group could
     examine issues that exist for using the HTTP upgrade mechanism to
     upgrade to an arbitrary bidirectional protocol and produce
     recommendations for HTTP clients, servers, proxies and gateways
     that would allow various protocols to be used, to evolved and to
     compete for wide support.

   <jkemp> from HyBi wiki

   NM: however, sometimes [this other pattern?] is more appropriate.
   the trade-offs are...

   JAR: I expect this advice is already known by the relevant

   <DC:> [it's not at all clear to me that what websockets is for is
   written down anyplace mere mortals should be expect to find]

   TBL: even in non-RESTful cases, self-description is nice... e.g.
   SMTP "explain"

   NM: it's not clear to me that the community knows this stuff. I get
   questions about how to think about such things. That's the main
   value I get out of TAG findings

   AM: in the Web Services world, there are at least a couple specs
   that tell you how to do this: WS-notification, WS-eventing... those
   are significantly more complicated; they have: subscribe, timeout,
   unsubscribe... pub/sub

   JK: I think this is much lower layer

   AM: transport layer?

   JK: yes

   HT: NM, when you asked about the TAG's feelings on RESTful access...
   I'm surprised you didn't mention the use of GET for something that
   can do things

   TBL:'UPGRADE' is a get-out-of-jail-free card -- it means the
   semantics of the request are changed

   HST Ah, ok

     <timbl> GET /demo HTTP/1.1
     Upgrade: WebSocket
     Connection: Upgrade
     Host: example.com
     Origin: http://example.com
     WebSocket-Protocol: sample

   <jkemp> ^sample is from

     [45] http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-43

   TBL: historically, I thought of UPGRADE for switching to X
   windows... but are there other uses of UPGRADE?


   <jkemp> (^sample is from)

   <jkemp> [46]http://www.ietf.org/rfc/rfc2817.txt

     [46] http://www.ietf.org/rfc/rfc2817.txt

     <masinter> Presently HttpCore provides support for HTTP CONNECT
     method for establishing end-to-end tunnels across HTTP proxies as
     specified in the RFC 2817. However, HttpCore currently does not
     support 'Upgrade' / 101 (Switching Protocols) handshaking, which
     does not seem as widely used by the common HTTP agents and servers

   <masinter> [47]http://issues.apache.org/jira/browse/HTTPCORE-158

     [47] http://issues.apache.org/jira/browse/HTTPCORE-158

     <masinter> ISA Server does not support the Upgrade header. If a
     client sends a request containing this header, it is ignored by
     ISA Server. Both client and server will use standard protocols.


     [48] http://technet.microsoft.com/en-us/library/cc302548.aspx

   <ht> [49]http://issues.apache.org/jira/browse/HTTPCLIENT-751

     [49] http://issues.apache.org/jira/browse/HTTPCLIENT-751

   JK: The hybi activity seems to have started to document best
   practices, because of perception that straight HTTP isn't meeting
   the need.

     <ht> 2008-02-11: "AFAIK, we're not supporting upgrade of a plain
     HTTP connection to HTTPS. We only support dedicated https:
     connections so far. HttpClient 4.0 should be flexible enough to
     add support for protocol upgrades. "

   <ht> [50]http://markmail.org/message/5zhsaxe3bnbd7cee

     [50] http://markmail.org/message/5zhsaxe3bnbd7cee

   JK: Additionally, the W3C Websocket work has been sent to IETF, but
   there are others in IETF hybi who believe that websockets isn't the
   best way to meet the need.

   JAR: If there's this much activity, it sounds like maybe we should
   table this for now.

   JK: There's good stuff on their wiki.

   DC: When the IETF is working on a charter, think to do is not to

   JAR: Sounds like materials are there.

   DC: Can't say.

   LMM: if we like the idea of best practices work, we could give that
   input now

   JK: there are other proposals...

   DC: I learned today about the message-oriented framing. That was
   useful, thanks.. Use cases on first slide and issues was also
   helpful, as was learning about status of WG. So, this was what I had
   in mind.

   <scribe> scribenick: DanC_

   NM: when we hear about other mechanisms... has the implementation
   train already left the station?

   LMM: no... there's quite spirited discussion among representatives
   from Opera, XMPP, Linden labs....

   NM: but about browsers...

   JK: I think there has been little, but it's starting.

   NM: Net, net, would people retune e.g. Firefox impl?

   DC: Yes.


     [51] http://www.ietf.org/mail-archive/web/hybi/current/msg00559.html

   HT: does the hybi wiki cite this among others?

   JK: yes

   <ht> [52]http://trac.tools.ietf.org/bof/trac/wiki/HyBi

     [52] http://trac.tools.ietf.org/bof/trac/wiki/HyBi

   <masinter> [53]http://trac.tools.ietf.org/bof/trac/wiki

     [53] http://trac.tools.ietf.org/bof/trac/wiki

   <masinter> [54]http://www.faqs.org/rfcs/rfc2324.html

     [54] http://www.faqs.org/rfcs/rfc2324.html

   <masinter> XXXX is based on HTTP. This is because HTTP is
   everywhere. It could not be so pervasive without being good.
   Therefore, HTTP is good. If you want good coffee, XXXX needs to be
   good. To make XXXX good, it is good to base XXXX on HTTP.

   [adjourn for break]

   [resume from break]

   HT: I hope to hear from LMM about the upcoming [Hybi] BOF

   LMM: we could consider this a liaison activity... we expect ...
   [pronoun overload; which "they"?]

   <masinter> I'm intending to be at IETF meeting and hope to attend
   HyBi BOF, but I don't have a commitment to do so, although I'm
   interested in the topic personally.

   TBL: seems to me people are doing roughly the right thing; I'd be
   more motivated to act if it looked like they were doing something

   LMM: it's encouraging that W3C working groups are taking protocol
   work to IETF


   <trackbot> ACTION-301 -- John Kemp to review websocket protocol/api
   motivation and brief TAG at Sep ftf -- due 2009-09-24 -- OPEN

   <trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/301

     [55] http://www.w3.org/2001/tag/group/track/actions/301

   close action-301

   <trackbot> ACTION-301 Review websocket protocol/api motivation and
   brief TAG at Sep ftf closed

   DanC: how about a similar session on web storage apis? Maybe I'll
   twist arms in a break...

Naming Schemes

   <ht> [56]http://www.ltg.ed.ac.uk/~ht/tag_persist/

     [56] http://www.ltg.ed.ac.uk/~ht/tag_persist/


   <trackbot> ACTION-33 -- Henry S. Thompson to revise naming
   challenges story in response to Dec 2008 F2F discussion -- due
   2009-09-18 -- OPEN

   <trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/33

     [57] http://www.w3.org/2001/tag/group/track/actions/33

   HST presents "Forever is a long time: Real persistence for the Web"

   HT: with that, on to JAR's suggestion...

   JAR: so take any competent repository administrator or librarian...
   they're dealing with all sorts of strings, whether they start with
   http: or doi: or otherwise... and on behalf of their users, they
   keep track of what these things mean they're going to build or buy
   or find a resolver... one choice of providers is ICANN/HTTP/DNS ...
   this pattern will hold regardless of which URI scheme they are using

   <masinter> need to be careful to talk about the service provider for
   name resolution and the guarantee for being the authoritative
   service for resolving the name

   JAR: suppose the repository manager believes me when I say "you can
   use HTTP URIs"... they'll be in the same situation as with urn: or
   other syntactic forms, they'll be in the same position of
   build/buy/find a resolver... could be a database, proxy, alternate
   DNS, etc.

   <masinter> I think i really understand this now and i'm frustrated
   at not being able to explain it

   <masinter> [58]http://larry.masinter.net/duri.html

     [58] http://larry.masinter.net/duri.html

   <masinter> is one proposed solution

   JAR: so if they find some other resolver, they're doing something
   that's not sanctioned by Web architecture; not using ICANN/DNS/http

   [fixing a bug in ICANN/DNS/http doesn't seem like something "not
   sanctioned by Web architecture"]

   <masinter> the obtainer of a name gets a "name", but implicitly they
   get some kind of service guarantee from a name service provider,
   that for the period they have purchased, the name service provider
   will tell other people that the name they are using means what the
   original name obtainer meant

   <masinter> the discussion Henry and JAR tell confuses who gets the
   name, who makes the service guarantee, and who is looking up the
   name and obtains the name resolution

   <Zakim> DanC_lap, you wanted to offer that w3.org falling into the
   hands of bad guys is analagous to a linnean animal name morphing
   into a trademark for some megacorp

   <masinter> using the "wayback" machine leaves open the question of
   how far back you go

   <masinter> AWWW looks at "meaning" from the wrong end of the
   telescope. Meaning can't change based on operational behavior

   DC: Not clear why the hypothesised situation would break WebArch

   <masinter> if you get a linnean name, you get something from an
   organization that offers a long-term name resolution service

   <noahm> ... Over time browsers would migrate to new URIs for W3

   LM: another attempt to explain what I've tried many times... when
   you get a name, you think you're getting something. But what you're
   really doing is entering into an agreement with a provider who
   offers the service of resolving a name

   <masinter> [59]http://larry.masinter.net/duri.html

     [59] http://larry.masinter.net/duri.html

   LMM: [... trust me as an authority]. the urn: scheme delegates that
   to [one place] and http: delegates via ICANN/DNS/etc. one idea I've
   put some work into is to add a timestamp to a URI... duri means what
   that URI meant in the given date the current practice in academic
   citations for web pages is to note the date of access

   <DanC> (the authority for the Linnaean names is the peer-reviewed
   academic community)

   <DanC> (which was once one of the few people would could get things

   <jkemp> authority is not noted in the name itself

   HT: well, let's please get back to evaluating the AWWW story about
   naming and authority

   NM: perhaps we should push harder on having some DNS names where
   persistence is more guaranteed. e.g. a new root

   <masinter> good papers in

     [60] http://www.isr.uci.edu/events/twist/twist99/

   HT: the "more persistent DNS names" idea is good, but making the
   domain name/owner binding stronger doesn't amount to a guarantee
   that it's perfectly strong

   <Zakim> timbl1, you wanted to say one can always make a different
   resolver for http uris so long as it doesn't misrepresent -- so long
   as it doesn't give wrong data, where right data is

   NM: [missed some subtlety about the stronger DNS idea]

   <masinter> AWWW is wrong because [61]http://www.w3.org/anything
   means "open HTTP connection to www.w3.org and ask it about
   "/anything". If you want something else you need "tdb", it's not

     [61] http://www.w3.org/anything

   <masinter> and it doesn't matter how much you wish anything else

   <noahm> I was noodling on the possibility that the guarantee would
   be such that W3C or anyone else "owning" a DNS name would have
   complete control over lines of succession for it.

   TBL: JAR, there are lots of times when people know what an http URI
   name means without doing an http lookup; that's fine as long as it's
   not inconsistent with what you'd get if you did a lookup

   <Zakim> timbl2, you wanted to suggest that extreme scenarious make
   bad design. Extreme situations occur with other things -- librraies
   with species in can get hacked, and specifically

   <masinter> the leap of faith needs to be explicit

   JAR: I'm talking about people using resolvers that are inconsistent
   with what you'd get with a lookup; e.g. OpenDNS resolves DNS names
   that normal DNS doesn't

   TBL: starting with a screw case doesn't make for a good argument.
   The case of W3C losing w3.org is uninteresting.

   TBL: The Commerce Department will take domain names by eminent

   TBL: HT started by saying the Linnaean name system works great, but
   of course somebody could replace all the books in the library to
   screw it up.

   <Zakim> timbl3, you wanted to say that in fact in a less wildy
   extreme scenario, in fact there is n serious value in pursuing more
   persistent domain names which the TAG could follow up

   <masinter> 'meaning' is a verb, not a noun. a URI producer 'means'
   something and a URI consumer attempts to discover what the URI
   producer meant. To define 'meaning' as a noun in AWWW confuses these
   things. We're asking producers to have faith that http: URIs to mean
   what they want to mean, in order that future consumers can readily
   discover their meaning.

   <DanC> (HT, recall that I pointed out that the URI would slowly
   degrade if the divergence between the software and the server at
   w3.org disagreed.)

   <noahm> (DanC, I'm not so sure -- why? Everything would continue to
   work if both browsers and users continued to use it as the NS URI)

   <DanC> (because people would not want to be associated with what the
   bad guys publish there)

   <jar> timbl: New TLD for use e.g. for persistent http:

   <noahm> ACTION Noah to schedule discussion of a persistent domain
   name policy promotion

   <trackbot> Created ACTION-311 - Schedule discussion of a persistent
   domain name policy promotion [on Noah Mendelsohn - due 2009-10-01].

   <DanC> ("permanent names" is a category error. as LMM points out,
   the request is for "permanent services" which is clearly absurd.)

   <Zakim> timbl4, you wanted to point out that this is a question of
   trust, and trust has a lot of Not Invented Here to it, and many
   people will trust something when and only when they have been

   TBL: the actual case in the lifesci community is about trust...
   somehow they trust the LSI committe but not ICANN...

   <masinter> [62]http://www.isr.uci.edu/events/twist/twist99/
   "problems URIs don't solve"

     [62] http://www.isr.uci.edu/events/twist/twist99/

   TBL: maybe if they'd been on the ICANN committee they'd trust them
   more... or if they'd been involved in HTTP [ESPEAKINGTOOFAST. bzzt.]

   LMM: I think AWWW/webarch is wrong because it makes an implicit leap
   of faith which needs to be explicit...

   <timbl> You can by the way bind the persistence not to an
   organization but to content (or meaning if you can define that)

   LMM: the step of opening up a connection is implicit... and this
   leads to contradictory conclusions

   <DanC> (it spells out that stuff a few sections lower)

   <jar> there are no guarantees

   LMM: if I write a URI in a book, and [something changes] it doesn't
   change the meaning of the book. Permanent names don't solve the
   problem that they're hoped to solve... financial failures etc. ...
   you come to the conclusion... that alternatives are no better than

   LMM: and in cases like doi and [missed], they're in a commercial
   position that we're in no position to argue down

   <DanC> (lmm, sorry, I'm afraid I mangled what you said)

   <Zakim> jkemp, you wanted to note that Linnaean names don't contain
   an authority

   JK: Linnaean names have the feature that resolution isn't part of
   the name... I can use google...

   <jkemp> neither resolution nor (any statement about) authority are
   included in Linnaean names

   <jar> actually careful biologists will specify the last name of the
   author of the authoritative publication...

   <masinter> implicitly 'search' becomes the naming system; it's a
   problem with folksonomies

   <DanC> huh? resolution is involved any time anybody utters a
   Linnaean names and hopes somebody to understand

   <Zakim> DanC_lap, you wanted to note persistence guarantees mostly
   come from either $$/lawers or rich social networks/communities

   DC: The way you get persistence is either by protecting it with $$$
   or with a large distributed community. IETF is a good example.
   Persistent names is a category error, not persistence names, but
   persistence services and persistent services are absurd. Endowed
   publication is a great idea

   TBL: UK gives special status to e.g. the National Trust -- you can't
   get their land off them w/o an act of Parliament

   HT: yes, Tim, you're right, hard cases make bad law... but certain
   constiuencies are obligated to consider the hard cases... these
   scholarly edition communities and lifescience identifiers
   communities can't avoid it this ( URI ownership) is all
   webarch says about how URIs get their meaning

   DanC: no, there's another section on how to resolve URIs

   HT: but that says nothing about meaning

   <jar> I think how to resolve is not the issue

   DanC: see the intro, on the relationship between representations,
   URIs, and resources

   <jar> (discussion of authority. is there a bug in awww.

   LMM: I disagree that the owner determines the meaning of the URI...

   <noahm> LMM: A URI does not lose its meaning because a service
   provider fails to deliver on their contractual obligation

   <noahm> (HST, e.g. with respect to resolving the domain name part)

   JK: You can type the URI into google

   DC: Consider the way phone numbers work -- if you stop paying for
   your phone, its number will eventually get recycled to call someone

   <Zakim> jar, you wanted to talk about GBIF WG solution

   LMM: It should say that if the ISP misbehaves the meaning of a URI
   doens't change. Tim: When we define a protocol, we say that if
   everyone obeys these rules, these are the good properties which
   result. We don't address normally what happens if you don't obey the

   <Zakim> masinter, you wanted to give some references to twist99
   talks and to disagree that the owner of the domain is the
   "authority" to determine what the URI "means"

   jar: the GBIF task force on identifiers decided that http URIs can
   be considered persistent, with alternative resolution option as an
   insurance policy against domain name loss. is this approach
   consistent with AWWW and the RFCs?

   <DanC_lap> [... and that little clause, even if it never happens,
   allows these communities to buy in.]

   <Zakim> DanC_lap, you wanted to note that IMGT allele names are
   being revised this year; things change; these communities deal

   <jar> (noting that the GBIF folks tried out urns, and couldn't make
   them work... not necessarily through any fault of their own)

   DC: You have to get people to use names to get them to mean
   anything. Speaking of hard cases the IMGT community are deciding to
   change all their names

   JAR: They are ill-advised

   <DanC_lap> ("the way"? it's an important way... a distinguished
   way... but not "the way")

   <jar> noahm: usually you poke on something's URI to find out what it
   is, but this doesn't always work. you have to reverse engineer

   NM: If I have a URI which identifies a webcam view of my back door.
   If someone else looks at it five nights running, they will
   legitimately conclude that my URI identifies a blank page

   <jar> (LRDD would be the way you communicate what it's supposed to

   NM: The only definitive way to find what a URI means is to go to the
   owner and ask them

   LM: No, that's just wrong -- AWWW is broken insofar as it says that

   NM: [gives an example, scribe missed]

   LM: Scenario 1: I give you a URI. Scenario 2: I give you a URI, but
   I tell you at the same time that the URI identifies a piece of
   paper, which I hand you. In scenario 2, the URI is useless

   JAR: W3C specs are full of this -- they say "This URI means...."
   without any necessary correlation with what you get with GET

   TBL: Do you mean, e.g., OWL spec says this that and the other are
   properties what's wrong with that?

   LM: [put a document in a drawer -- scribe didn't catch]

   DC: Can I assign meaning to numerals?

   LM: You can't -- you can only tell me what you mean by them

   JK: We've established community consensus that 23 comes after 22

   DC: I give up

   HT: I'd like to pick that up sometime

   LMM: yes, I've been looking forward to this conversation

   HT: Wrapping up... I'd like to come back to this sometime... I've
   heard some endorsement of the claim that webarch is incomplete/wrong
   on how URIs get and retain meaning...

   NM: any other concluding remarks?

   LMM: I think trust/belief are important... this conversation where
   Dan was getting frustrated... I think he was saying things that
   seemed obvious and I wasn't agreeing because he was leaving out

   <jar> dan likes the succession clause (see my comments above about

   DanC: my take-away is that this succession [sp?] clause is
   interesting... the fact that it allows people to get on with it
   seems great.

   NM: the idea about more-permanent DNS names seems interesting...
   also, this idea that you can discover resource meaning by
   experiment... that it only sometimes works is interesting


   <trackbot> ACTION-33 -- Henry S. Thompson to revise naming
   challenges story in response to Dec 2008 F2F discussion -- due
   2009-09-18 -- OPEN

   <trackbot> [63]http://www.w3.org/2001/tag/group/track/actions/33

     [63] http://www.w3.org/2001/tag/group/track/actions/33

   HT: I don't think this is higher priority than review of HTML, but
   I'd like to get back to it

   <scribe> ACTION: jar to find a path thru the specs that I think
   contradicts Dan's reading of webarch [recorded in

     [64] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04

   <trackbot> Created ACTION-312 - Find a path thru the specs that I
   think contradicts Dan's reading of webarch [on Jonathan Rees - due

   <jar> (the topic of how to find out what resource is meant has come
   up twice in this conversation, from noah and from ht - the idea that
   doing GETs is not adequate to find out what it is. ashhok and jar
   chant 'LRDD')

   <jar> (and i think this orthogonal to the main conversation)

   Adjourned until tomorrow

Summary of Action Items

   [NEW] ACTION: Henry S. to bring back proposed TAG pushback on
   sniffing and HTTP bis draft
   -httpbis/latest/p3-payload.html, or his recommendation that we leave
   it alone [recorded in
   [NEW] ACTION: jar to find a path thru the specs that I think
   contradicts Dan's reading of webarch [recorded in
   [NEW] ACTION: John to propose updates to Authoritative Metadata and
   Self-Describing Web to acknowledge the reality of sniffing, due
   2009-10-20 [recorded in
   [NEW] ACTION: Noah to check with Sam Ruby on ECMA/W3C activities at
   TPAC [recorded in

     [66] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action02
     [67] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action04
     [68] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action01
     [69] http://www.w3.org/2001/tag/2009/09/24-minutes.html#action03

    Minutes formatted by David Booth's [70]scribe.perl version 1.134
    ([71]CVS log)
    $Date: 2009/09/29 10:53:15 $

     [70] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [71] http://dev.w3.org/cvsweb/2002/scribe/


      [1] http://www.w3.org/

                               - DRAFT -

                     TAG F2F day 3 -- 25 Sep 2009

25 Sep 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/09/25-tagmem-irc


          jar, masinter, noahm, DanC, noah, TimBL, ht, johnk, raman


          Noah Mendelsohn

          Ashok Malhotra, Jonathan Rees


     * [3]Topics
         1. [4]HTML Issues
         2. [5]HTML
         3. [6]HTML Data Facilities
         4. [7]TAG admin (TPAC logistics, future meetings)
         5. [8]TAG priorities
         6. [9]HTML issue: text/html mime type
         7. [10]Geolocation/Geopriv
     * [11]Summary of Action Items

   <Ashok> scribe: Ashok Malhotra

   <Ashok> scribenick: Ashok

   Noah: reviews the agenda
   ... I would like to spend majority of our time on HTML
   ... skip TAG Priorities
   ... Let's do admin right after lunch

   Jar: Let's ask people what they are gonna do

   Noah: Let's use Action Item list

HTML Issues


   Noah: What should be next topic for discussion

   Larry: I thought were close to consensus on sniffing

   Noah: Let's do it on a telcon

   Larry: I think we could come up with a position on it.

   HT: I have action to propose pushback or accept status quo

   Noah: Who wants to discuss sniffing now?

   <DanC_lap> action-309?

   <trackbot> ACTION-309 -- Henry S. Thompson to s. to bring back
   proposed TAG pushback on sniffing and HTTP bis draft
   -httpbis/latest/p3-payload.html, or his recommendation that we leave
   it alone -- due 2009-10-01 -- OPEN


   <trackbot> [13]http://www.w3.org/2001/tag/group/track/actions/309

     [13] http://www.w3.org/2001/tag/group/track/actions/309

   HT: My inclination is to ask them for a health warning

   Larry: I would like to discuss for 10 mts

   Poll 3 to 1 ... not now

   Noah: What next item to discuss

   DC: Data facilities

   HT: I would like to report what I found out wrt item 13

   HT to give 3 minute report on item 13

   HT: I took the binary attribute case

   Tim: Boolean

   HT: I explored that whereever there was an error there should be
   error recovery case
   ... I sent mail and was told "No, what you say goes in the DOM"

   <DanC_lap> (ht, did you say "it's all in public-html"? I don't see
   it in
   tml )


   HT: Reason is -- this is an extensibility point

   <DanC_lap> (false advertising. this is discussion. not

   Larry: Is input disabled or is it not?

   <DanC_lap> ah... found it: Where is processing of binary attributes
   covered? Henry S. Thompson (Wednesday, 23 September)


   HT: It IS disabled
   ... Binary attributes are true if present, false if not present

   Larry: So, disabled = false results in TRUE

HTML Data Facilities

   Tim: 2 overlapping concerns --- how should data be handled in HTML,
   --- overlap with extensibility of tags
   ... it's important to put RDF into HTML
   ... RDFa spec tells you how to do that.
   ... Hixie said removing namespaces was a goal, and it's hard to use
   RDFa without namespaces.

   Noah: Shall we separate extensibility concerns?

   Tim: I'm happy to discuss microdata and Hixie's special data format

   <jar> 'rdfh' ... I'd like to hear more about this

   Tim writes on board --- RDF in HTML, RDF, microformats,
   Data-Attributes, ---- no NS in HTML, Extension Tags

   Tim: These are various positions people have taken

   <noahm> We are using the queue

   <noahm> I think

   jar: Has anyone articulated that you might do RDF in HTML w/o

   DC: There is a proposal

   <jar> the answer was: Yes, data-... does RDF in HTML, but only an
   (albeit useful) subset.

   Tim: Some say don't bother with namespaces; others say give me the
   namespaces tool

   <DanC_lap> TBL: the blobs [in the whiteboard diagram] are positions;
   the x's are issues.

   Larry: HTML5 now has a data format based on no known experience

   DC: No deployment of the data stuff

   <DanC_lap> blobs = RDF in HTML, RDFa, Need NS in HTML, microformats,
   data-*, No NS in HTML, Extending Tags

   jar: You could extract triples from data-attributes

   DC: That code has been written

   Discussion about whether data- or item-property

   Noah opens HTML spec

   DC: 5.2 Microdata

   5.2 Encoding microdata

     [16] http://dev.w3.org/html5/spec/Overview.html#encoding-microdata

   [17]http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute Embedding custom non-visible data

     [17] http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute

   DC: Custom data attributes:

   Noah: What is difference between data- and the item stuff
   ... if you do data- you get a Javascript object with that name

   DC: What's the motivation?

   Noah: Extends that data space for Javascript programmers

   HT: It's a way of extending attribute space
   ... The para after the note is the justification

   Noah: How [?] different from item-
   ... is there a glimmer of a comment here?

   JK: There may be another position --- no NS mapping rather than no

   Noah: There is third position ... just use short names and handle

   Tim: The item- maps to a URI

   JK: Section 5.1.3 in WHATWG spec
   ... says "As URLs"

   Larry: This section is non-normative

   Tim: This is a competing proposal to RDFa
   ... subject is where it is attached to

   Looking a frag in 5.1.2

   Tim: Item property can be a URI or a reverse domain name thingie

   Noah: Both data- and item overlap with RDFa
   ... could extract RDFa from this

   jar: That is not a usecase

   <Zakim> johnk, you wanted to note that I believe "no namespace
   prefix mapping" is more accurate than "no namespace"

   Discussion on whether RDFa can be represented in this form

   Tim: Go to 5.1.4 and look at example
   ... 2 properties of Hedral

   JK: Section 5.2.3
   ... Associating names with Items

   HT: In 5.1.1 near the end --- properties don't have to be given as
   descendents of the element with item attribute
   ... They can be associated with a specific item using the itemfor
   attribute which takes the ID of the element with the item attribute

   DC: There is a well-known pattern for licenses for images. Is that
   expressible in this syntax.

   <timbl> [18]http://dev.w3.org/html5/spec/microdata.html#overview

     [18] http://dev.w3.org/html5/spec/microdata.html#overview

   HT: Properties that also have values that are URLs. This is achieved
   by using the a element and the href attribute, ....

   Tim: 5.5.2 RDF ...

   <ht> Looks to me that <img src="....." item /> <div style="display:
   hide"><a href="xxxxx" itemprop="[CCREL]"></a></div> will do it

   Tim: We could make a comment about the process

   <Zakim> ht, you wanted to ask about <script

   HT: Minor aspect of script which says the script item is used to
   introduce script or data ... type of data is given by type attr of

   <Zakim> noahm, you wanted to say, I claimed this stuff was related
   to GRDDL more than RDFa and to

   HT: does not say what you can do with the data

   <jar> ben a: " it makes things much more roundabout to write since
   itemprop applies to both (either?) @href and the element content"

   HT: The item I put in IRC log will do what jar asks
   ... I left out the ID and the item4

   <ht> <img src="....." item id="photo7" /> ... <div style="display:
   hide"><a href="xxxxx" itemprop="[CCREL]" subject="photo7"></a></div>

   Tim: Critiques the algorithm

   <ht> more recent draft uses 'itemfor' for 'subject'

   Tim: There is incredible tension between communities expressed on
   the board
   ... TAG could perform useful function.
   ... is it functionally equivalent to RDFa, or not?

   <DanC_lap> ht, we could try out the example you made...

   <DanC_lap> [10:17] <Philip> DanC_lap:
   [19]http://philip.html5.org/demos/microdata/demo.html ?

     [19] http://philip.html5.org/demos/microdata/demo.html

   <DanC_lap> [10:18] <Philip> Also

     [20] http://james.html5.org/microdata/

   Larry: I'm concerned about us not driving to statements

   <DanC_lap> [10:17] <Philip> DanC_lap:
   [21]http://philip.html5.org/demos/microdata/demo.html ?

     [21] http://philip.html5.org/demos/microdata/demo.html

   <DanC_lap> [10:18] <Philip> Also

     [22] http://james.html5.org/microdata/

   Larry: I have a process suggestion
   ... create statements and choose between them

   DC: That may be helpful

   Larry: 10 minutes to solicit things we may say

   <noahm> JAR: One thing we might say [straw man] is: "HTML has to
   adopt namespaces and RDFa" (not sure I believe that, but it's one
   thing we might want to say)

   <jar> or reject

   <DanC_lap> LMM: I see no justification for reverse domain name
   labels where URIs would solve the problem

   <DanC_lap> tbl 2nds

   Larry: No justification for introducing reverse domain-based
   namespace mechanisms are adequate

   <DanC_lap> s/are allowed/are adequate/

   <jar> (jar was confused by 'reverse DNS' - I think what's meant is
   "reversed domain names" and is not related to reverse DNS lookup)

   Tim: RDFa and item- are almost identical functionality
   ... so they create fragmentation which is always damaging

   <johnk> Notes:
   3-Quin01.html on "automatic XML namespaces"


   HT: Introducing a new unimplemented and untried design where there
   is an implemented tried design is not helpful

   <Zakim> DanC_lap, you wanted to say we might say that RDFa should
   have no special status just because it's a REC, since W3C allowed it
   to go thru CR without coordination with HTML 5

   <jar> is there a requirements statement for item, itemprop etc? is
   rdf capture a requirement? where articulated?

   Noah: The item- is simpler syntactically ... I'm half-convinced
   about this

   <johnk> ... and
   "pragmatic XML namespaces"

     [24] http://lists.xml.org/archives/xml-dev/200907/msg00157.html

   Noah: not enough justification for duplication

   <DanC_lap> (re "would anybody use microdata?" there's a relevant
   thread at
   tml#msg732 )


   Tim: RDF is REALLY simple
   ... first notation for mapping RDF to XML was really complicated

   <johnk> "How to make namespaces in XML easier":

     [26] http://ln.hixie.ch/?start=1151612438

   <noahm> I heard Tim say the opposite; I heard him say RDF as a model
   is inherently very simple, but RDFa (and also RDF/XML) is
   suprisingly complicated

   Tim: there is a lot of parser state to be carried along

   <ht> s/RDFa is simple/RDF is simple/

   <noahm> For those curious about my "Tim said the opposite" comment,
   our scribes used log edits to fix what Tim said. I do not believe
   said the opposite of the fixed comment.

   <timbl> ... aka /opposite/d

   BREAK till 10:50

   <timbl> I said that RDF/XML was surprisingly complicated, people
   saying that that came from its attempt to look like "colloquial
   XML"; that we had a few other attempts at syntaxes, including N3,
   and then in *ML again we had RDFa, maybe the fourth, which to me was
   surprisingly complicated, involving a surprising amount of state to
   be held by the parser duriung its recursive descent, and now we have
   RDFb (lets call it) whcih attempts the same thing, and again is

   <timbl> complicated when you look at the algorithm. Is there a
   fundamental difficulty to this challenge?

   JK: I pasted a link about distributed extensibility above

   <noahm> Chair notes that we are filling some time talking about
   proposals that are floating around for namespace-based extensibility
   until Tim gets back.

   JK: there are other proposals: Liam Quin and Tim Bray's delta on
   Micah Dubinko's proposal



   <noahm> JK: First proposal is Balisage proposal from Liam Quin

   <masinter> references include pointer to

     [28] http://ln.hixie.ch/?start=1151612438

   HT: This says we are going to associate NSs with some elements. Does
   away with prefixes

   DC: There is some outboard doc that gives the mapping

   HT: Processors will bake in a version of the doc they support

   Noah: Some will be baked in, others [specified] in an outboard doc

   DC: Does this work like static scoping?
   ... if elements indicate namespaces then it's like static scoping

   <johnk> xml-dev collated proposal

     [29] http://www.dpawson.co.uk/namespaces/index.html

   JK: This where the thread that Micah started ended up ... this has
   notion of reverse domain syntax
   ... Micah's email


     [30] http://lists.xml.org/archives/xml-dev/200907/msg00157.html

   HT: This is too disruptive, so it's a non-starter

   Noah: Do we continue on Data Facilities? or move to other topics?

   <Zakim> DanC_lap, you wanted to say that complexity for the parser
   is often anti-correlated with complexity for the author

   <Zakim> danc2, you wanted to ask who are the daily minutes-editors

   DC: There are 2 kinds of complexity: for authors and for parser

   Tim: If it's hard to write the parser it's hard for authors

   <noahm> In about 7 minutes, which will be ~ halfway through, I will
   stop discussion to see if we are closing in on next steps.

   <jar> danc: Syntactic sugar and defaults make authoring easier but
   parsing harder

   Discussion about syntactic sugar

   Tim: 2 pieces --- triples and triple state

   <DanC_lap> TBL: both [sorts of complexity] make learning the
   language harder

   <masinter> and also that 'data' and 'metadata' are really the same

   DC: Do users grok or not .... people pick up RDFa and use it. People
   don't use microdata

   <masinter> and also that i think the charter of the group and the
   right answer is that neither RDFa nor data should be part of HTML
   spec and are out of scope for group's charter, group was charatered
   to produce extensibility

   Larry: HTML WG was not chartered to do any of this work .... this
   ought to be out of scope
   ... area should be able to evelove independently from the HTML

   <timbl> [31]http://www.w3.org/TR/rdfa-syntax/

     [31] http://www.w3.org/TR/rdfa-syntax/

   Larry: HTML is not usually written by humans; it is generated from
   database tools
   ... complicated tool chains
   ... one of the proplems with NSs is that NS-based markup does not
   cut and paste well

   <Zakim> masinter, you wanted to talk about complexity for tools for
   generating, ability to mash-up, ability to copy-paste

   <masinter> without moving to dom

   <Zakim> danc3, you wanted to note complexity discussion currently

   DC: There are various threads about complexity of HTML5. Opportunity
   to get involved in current discussion

   <Zakim> johnk, you wanted to ask Larry if he thinks that's true with
   XHTML changes

   <DanC_lap> Complexity of HTML5 (was Re: The Complexity Argument)
   Maciej Stachowiak (Sunday, 20 September)


   JK: Asks about charter? Should it still be true given that XHTML is
   winding down.
   ... there are specific needs to do the extensibility

   <Zakim> DanC_lap, you wanted to note sympathy with the "add an
   extensibility mechanism, not RDFa nor microdata directly" position;
   GRDDL was based on the head/@profile extensibility

   Larry: W3C should charter a group on Metadate .... how to add
   Metadata to HTML

   DC: Talks about GRDDL as an example

   Tim: Are people using GRDDL?

   <johnk> DC: notes that GRDDL extensibility is achieved by use of the
   HTML profile attribute

   JAR: There are (this is irrelevant) XSLT that parse RDF/XML and
   produces triples

   DC: Community not supporive of my suggestions on extensibility

   Tim: Talk about problem with cut/paste of NS-based markup

   <Zakim> timbl, you wanted to say that to have a de-prefixed from for
   cut and paste woul dbe reasonable.. this works with attributavalues
   abut not alas with element names. You can for

   Tim: Are there oher reasons why people do not like Namespaces

   Noah: We need an Action

   <timbl> More generally, to get more arcs in a motivation graph to
   elaborate what is on the whiteboard.

   <DanC_lap> timbl, another rationale behind the the "no URI prefix"
   position is: what happens when you mutate the DOM?

   Larry: The HTML WG has pointed out a flaw in XML and we should puch
   back on XML's syntax on Namespaces
   ... TAG could encourage re-examination of Namespaces

   <Zakim> noahm, you wanted to try and focus discussion and to talk
   about exploring namespaces

   Noah: Some sympathy but efforts like that may fail
   ... suggests some TAG action
   ... Should TAG analyze the situation?

   Larry: The TAG could endorse ongoing work outside and encourage a
   W3C activity to look into revising Namespaces

   HT: What is the flaw in XML which HTML has called attention to?

   <timbl> DanClap, re "no uri prefix" a reasonable position is that
   the prefix is just a shorthand, and the DOM is the data model, so
   the DOM should have the full URI. (Like the RDF model does). It is
   then a serialization option as o whether you se a prefix shorthand.

   Noah: Problems with Namespaces ... cut and paste problems, typing
   stuff with namespaces turns out to be harder than typing stuff

   <Zakim> ht, you wanted to ask LM to expand on "HTML requirements"
   for XML namespace design

   DC: DOM modifications

   JK: Sympathetic to Larry's proposal but we need to do our homework.
   We should speak to people at Balisage.

   Noah: Tries to clarify proposals

   HT: We misunderstood Larry use of the word "endorse".

   Noah: We need to do homework first

   Tim: Reminded of Cambridge Communique time

   Noah: Need specific actions

   Larry: We could ask XML Core to do some homework

   HT: This would require a charter change

   Noah: Worries about skill set. Needs knowledge of use of Namespaces
   in different contexts

   HT: Flaws in XML are not addressed by any of these proposals

   <johnk> HT: I heard two proposals - i) propose changes to XML Core
   ii) bring together HTML and XML folks to make a namespace proposal
   acceptable to both

   HT: Requirements did not have anything to do with HTML

   Larry: HTML WG found that current XML infoset serialization is too
   difficult for them.
   ... we should examine what infoset would meet their needs and also
   allow distributed extensibility

   <masinter> there is precedent for W3C working on alternative
   serializations of XML

   Larry: This is not a short-term comment to HTML WG. There is some
   long-term work that W3C should take up to prevent communities from
   forking off

   <masinter> this isn't the 'solution', but I am very concerned about
   W3C endorsing two separate forks of HTML on the one hand and XML on
   the other, and that perhaps this is 'research', but that the TAG
   should lead effort toward convergence

   <masinter> i don't want the default answer to be "oh well, i guess
   they're different, let's just leave them going off in different

   Tim: XML Model, HTML model and RDF model is a triangle. Trying to
   harmonize may be a mistake. Should be arms-lenghth relationship
   ... Narrow the scope to attribute values, not attribute or element

   Noah: Please type possible actions into IRC log

   <johnk> I am suggesting that I talk to those who went to Balisage,
   and ask what was discussed regarding the namespace-focused work
   there, and report back to TAG

   <timbl> In other words like microdata and RDFa, use the *ML DOM as
   it is and putthings in the attribute values.

   <DanC_lap> maybe invite advocates of a few of the positions tbl put
   on the board (see "blobs" above) to a TAG meeting to discuss them.

   <timbl> +1 to JohnK anyway

   <masinter> i suggest johnk also float the idea of further work
   specifically on this, and that we ask also HT to explore the
   questions with XMLCore

   <masinter> i suggest the tag also put out a position that we would
   like to see work in this area

   <noahm> Larry offers to take action to draft message that the TAG
   will endorse

   <masinter> possibility of coming up with a new serialization of
   infoset, which would be acceptable to HTML community, please explore

   HT: Larry phrased a new serialzation of the Infoset . I can ask
   XMLCore. Asking them to chamge XML would be much more contentious

   <masinter> "please ask the XMLCore group what in the area of
   discovering and meeting HTML's requirements they would be willing to
   do, and what prerequisites they would have for doing it"

   <masinter> i propose Henry do what I just typed

   Noah: Will you take an action to come back to TAG with a proposal
   for whether and how TAG should interact with XML Core re. Infoset

   HT: I don't know what HTML's requirements are

   Tim: Too vague ....

   HT: I will think about that

   <johnk> ACTION: John to talk to Balisage participants about XML
   namespace work, discuss TAG interest in this area, and summarize
   recorded in [33]http://www.w3.org/2009/09/25-tagmem-irc]

     [33] http://www.w3.org/2009/09/25-tagmem-irc

   <trackbot> Created ACTION-313 - Talk to Balisage participants about
   XML namespace work, discuss TAG interest in this area, and summarize
   [on John Kemp - due 2009-10-02].

   DC: Any volunteers to get the concerned players together?

   JK: I can ask the Balisage players

   <johnk> DC: That's not who I meant

   HT: No, the players for the consitituencies on the board

   Suggestions - invite Ben Adida, Manu

   Larry: Possibility of meeting at TPAC?


   Reconvene at 1:15 PM

   <jar> scribe: Jonathan Rees

   <jar> scribenick: jar

   dan does wed cleanup

   ht does thu cleanup

   jar does fri minutes cleanup

   noah will collate / link all minutes


   <ht> TV, dial in to discuss next meeting, please?

   <ht> Raman?

   <ht> T.V.?

   <timbl> People in the room wave to Raman.

   noah: admin review. note, membership is turning over a bit

   ht: All please think about who should stand for membership

TAG admin (TPAC logistics, future meetings)

   noah: Future meetings: TPAC and Dec 8-10

   Dec 8-10 will be at MIT again

   <DanC_lap> (anybody want to offer, here in IRC, to host a meeting?
   at least tentatively?)

   After that: An idea: co-locate TAG and IETF, Anaheim, March ?

   AC meeting is at MIT Mar 21-23

   Mar 21-23 is Sun-Tue. LM proposes TAG just before that

   scribe: more discussion of meeting planning ...

   Noah: MIT Mar 17-19 ?

   ashok: too early to tell

   (no one is saying they can't make that)

   Passed - subject to possible future modification - but for now let's
   plan on MIT Mar 17-19

   RESOLUTION: TAG F2F, MIT, Mar 17-19

   <scribe> ACTION: noah Check with Amy on room availability and
   suggest to Ian that he mention this meeting in TAG election call for
   nominations [recorded in

     [34] http://www.w3.org/2009/09/25-tagmem-irc

   <trackbot> Created ACTION-314 - Check with Amy on room availability
   and suggest to Ian that he mention this meeting in TAG election call
   for nominations [on Noah Mendelsohn - due 2009-10-02].

   <noahm> Who will be @ TPAC?

   <noahm> Henry, Dan, Ashok, Larry

   <noahm> TPAC regrets: John and Jonathan and Tim

   noahm: We will meet Mon am, Fri am; available to meet with other WGs
   at other times

   noah: We used to have TAG progress reports, that stopped at some
   point, any interest now? (probably not)
   ... Any WGs we want to reach out to?
   ... The meeting at plenary in France was really good

   <scribe> ACTION: DanC to follow up on best plan for HTML / TPAC
   recorded in [35]http://www.w3.org/2009/09/25-tagmem-irc]

     [35] http://www.w3.org/2009/09/25-tagmem-irc

   <trackbot> Created ACTION-315 - Follow up on best plan for HTML /
   TPAC [on Dan Connolly - due 2009-10-02].

   <amy> i confirm I've reserved space for 17 March in G449 (Kiva); 18
   March in room 346 (Kiva and Star were not available) and on 19 March
   in G449 (Kiva)

   <ht> Amy ++

   DanC: Re ECMA, Sam suggested Friday, but there was a conflict

   noah: Meet separately with ECMA folks?

   lm: primary discussion around ecma is around process, as much around
   technical work. we can make ourselves available of course


   <DanC_> action-310?

   <trackbot> ACTION-310 -- Noah Mendelsohn to check with Sam Ruby on
   ECMA/W3C activities at TPAC -- due 2009-10-01 -- OPEN

   <trackbot> [36]http://www.w3.org/2001/tag/group/track/actions/310

     [36] http://www.w3.org/2001/tag/group/track/actions/310

TAG priorities

   sort actions by owner

   <DanC_> action-116?

   <trackbot> ACTION-116 -- Tim Berners-Lee to align the tabulator
   internal vocabulary with the vocabulary in the rules
   [37]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
   either as needed. -- due 2009-08-01 -- OPEN

     [37] http://esw.w3.org/topic/AwwswDboothsRules

   <trackbot> [38]http://www.w3.org/2001/tag/group/track/actions/116

     [38] http://www.w3.org/2001/tag/group/track/actions/116

   <DanC_> action-116 due 1 Dec

   <trackbot> ACTION-116 Align the tabulator internal vocabulary with
   the vocabulary in the rules
   [39]http://esw.w3.org/topic/AwwswDboothsRules, getting changes to
   either as needed. due date now 1 Dec

     [39] http://esw.w3.org/topic/AwwswDboothsRules

   Timbl: It's good to be reminded of it

   <DanC_> close action-24

   <trackbot> ACTION-24 clarify [40]http://www.w3.org/2003/04/iri ,
   perhaps by using N3 closed

     [40] http://www.w3.org/2003/04/iri

   timbl: (refers to new IRI spec drafts)

   <DanC_> action-24: withdrawn in Cambridge. TBL suggests LMM consider
   stuff in this area

   <trackbot> ACTION-24 clarify [41]http://www.w3.org/2003/04/iri ,
   perhaps by using N3 notes added

     [41] http://www.w3.org/2003/04/iri

   lm: The new drafts should not influence whatever action is implied
   by this action item

   timbl: Would like to drop it.

   <DanC_> close action-24

   <trackbot> ACTION-24 clarify [42]http://www.w3.org/2003/04/iri ,
   perhaps by using N3 closed

     [42] http://www.w3.org/2003/04/iri

   Dan's actions:


   <trackbot> ACTION-307 -- Dan Connolly to raise issue of work items
   moving between W3C working groups and also with IETF -- due
   2009-09-30 -- OPEN

   <trackbot> [43]http://www.w3.org/2001/tag/group/track/actions/307

     [43] http://www.w3.org/2001/tag/group/track/actions/307

   lm: This is a process issue, I don't think it's finished
   ... Hypertext coordination group might take this on?

   danc: If I don't get this done today I don't want to carry it


   <trackbot> ACTION-299 -- Dan Connolly to notify the TAG when the
   HTML WG gets closer to closing issue-4 html-versioning -- due
   2009-09-10 -- OPEN

   <trackbot> [44]http://www.w3.org/2001/tag/group/track/actions/299

     [44] http://www.w3.org/2001/tag/group/track/actions/299

   <DanC_> action-299 due 15 Oct

   <trackbot> ACTION-299 Notify the TAG when the HTML WG gets closer to
   closing issue-4 html-versioning due date now 15 Oct


   action-295 due is 1 week

   <trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV
   comments on last call and report to the TAG due date now is 1 week

   danc: Discussion is out of order
   ... of the actions that is
   ... (Generally, not action) HTML validation software dev work that I
   might do

   (danc was addressing JAR's request to hear from everyone re tag work
   they planned for this fall)


   <trackbot> ACTION-308 -- John Kemp to propose updates to
   Authoritative Metadata and Self-Describing Web to acknowledge the
   reality of sniffing, due 2009-10-20 -- due 2009-10-01 -- OPEN

   <trackbot> [45]http://www.w3.org/2001/tag/group/track/actions/308

     [45] http://www.w3.org/2001/tag/group/track/actions/308

   action-308 due 20 october

   <trackbot> ACTION-308 Propose updates to Authoritative Metadata and
   Self-Describing Web to acknowledge the reality of sniffing, due
   2009-10-20 due date now 20 october

   lm: i don't like this action. you should refuse to do it

   danc: Out of order


   <trackbot> ACTION-313 -- John Kemp to talk to Balisage participants
   about XML namespace work, discuss TAG interest in this area, and
   summarize -- due 2009-10-02 -- OPEN

   <trackbot> [46]http://www.w3.org/2001/tag/group/track/actions/313

     [46] http://www.w3.org/2001/tag/group/track/actions/313

   action-313 due 20 october

   <trackbot> ACTION-313 Talk to Balisage participants about XML
   namespace work, discuss TAG interest in this area, and summarize due
   date now 20 october

   <DanC_> action-313 due 20 Oct

   <trackbot> ACTION-313 Talk to Balisage participants about XML
   namespace work, discuss TAG interest in this area, and summarize due
   date now 20 Oct


   <trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress
   of link header draft, report to TAG, warn us of problems (ISSUE-62)
   -- due 2009-10-30 -- OPEN

   <trackbot> [47]http://www.w3.org/2001/tag/group/track/actions/281

     [47] http://www.w3.org/2001/tag/group/track/actions/281

   ashok: ongoing


   <trackbot> ACTION-304 -- Larry Masinter to draft summary of the
   larger issue -- due 2009-09-30 -- OPEN

   <trackbot> [48]http://www.w3.org/2001/tag/group/track/actions/304

     [48] http://www.w3.org/2001/tag/group/track/actions/304

   noah: This is worth pursuing; need to look at minutes to see what
   it's about

   johnk: This was about the references in the HTML spec. HT had one
   action, LM suggested there was a larger issue around references

   action-304 due in one week

   <trackbot> ACTION-304 Draft summary of the larger issue due date now
   in one week

   johnk: What the web platform looks like.

   lm: I remember - I was going to add it to the versioning document

   <noahm> action-304?

   <trackbot> ACTION-304 -- Larry Masinter to larger around Web
   Platform Definition regarding references in HTML 5 document -- due
   2009-09-30 -- OPEN

   <trackbot> [49]http://www.w3.org/2001/tag/group/track/actions/304

     [49] http://www.w3.org/2001/tag/group/track/actions/304

   <masinter> regarding the definition of the 'web platform' with
   regard to specs defined in the HTML5 document



   <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-09-30 -- OPEN

   <trackbot> [50]http://www.w3.org/2001/tag/group/track/actions/306

     [50] http://www.w3.org/2001/tag/group/track/actions/306

   <masinter> the general idea is that the web platform consists of a
   set of interfaces, HTML, DOM, URI, RDF, images, etc., and that an
   overall spec defining the platform should then make reference to
   versionless versions of specs and alternatives

   close action-306

   <trackbot> ACTION-306 Work with JK and AM to update Web APplication
   architecture outline based on discussions at TAG meetings closed

   reopen action-306

   <trackbot> ACTION-306 Work with JK and AM to update Web APplication
   architecture outline based on discussions at TAG meetings re-opened

   ashok: Let's meet at the end of next month

   <DanC_> action-306: this is a follow-on action

   <trackbot> ACTION-306 Work with JK and AM to update Web APplication
   architecture outline based on discussions at TAG meetings notes

   <DanC_> action-306?

   noah: Please annotate the action in tracker?

   <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-09-30 -- OPEN

   <trackbot> [51]http://www.w3.org/2001/tag/group/track/actions/306

     [51] http://www.w3.org/2001/tag/group/track/actions/306


   <trackbot> ACTION-311 -- Noah Mendelsohn to schedule discussion of a
   persistent domain name policy promotion -- due 2009-10-01 -- OPEN

   <trackbot> [52]http://www.w3.org/2001/tag/group/track/actions/311

     [52] http://www.w3.org/2001/tag/group/track/actions/311

   ht: This was to follow up on Tim's plea to do something about
   persistence of w3.org or persistent domains generally

   [well that's not exactly what henry said.]

   <DanC_> action-311: tbl notes

     [53] http://www.w3.org/DesignIssues/PersistentDomains

   <trackbot> ACTION-311 Schedule discussion of a persistent domain
   name policy promotion notes added

   action-285 due in 2 weeks

   <trackbot> ACTION-285 Make sure TPAC logistics are straight due date
   now in 2 weeks

   <DanC_> action-285?

   <trackbot> ACTION-285 -- Noah Mendelsohn to make sure TPAC logistics
   are straight -- due 2009-09-25 -- OPEN

   <trackbot> [54]http://www.w3.org/2001/tag/group/track/actions/285

     [54] http://www.w3.org/2001/tag/group/track/actions/285


   <trackbot> ACTION-292 -- Noah Mendelsohn to alert group to review
   HTML Authoring Drafts [trivial] [self-assigned] -- due 2009-10-13 --

   <trackbot> [55]http://www.w3.org/2001/tag/group/track/actions/292

     [55] http://www.w3.org/2001/tag/group/track/actions/292

   noah will schedule discussion on this


   <trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web
   Application ( [56]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html
   ) outline with as many sentences as he can -- due 2009-09-15 -- OPEN

     [56] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

   <trackbot> [57]http://www.w3.org/2001/tag/group/track/actions/284

     [57] http://www.w3.org/2001/tag/group/track/actions/284

   <DanC_> ACTION-292: LMM notes Mike Smith's HTML spec is relevant

   <trackbot> ACTION-292 Alert group to review HTML Authoring Drafts
   [trivial] [self-assigned] notes added

   close action-284

   <trackbot> ACTION-284 Flesh out the Web Application (
   [58]http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline
   with as many sentences as he can closed

     [58] http://www.w3.org/2001/tag/2009/06/webAppsTOC.html

   awwsw is talking about tag dec f2f as a 'delivery date'

   action-312 due 1 december

   <trackbot> ACTION-312 Find a path thru the specs that I think
   contradicts Dan's reading of webarch due date now 1 december

   action-312 due in one week

   <trackbot> ACTION-312 Find a path thru the specs that I think
   contradicts Dan's reading of webarch due date now in one week

   action-201 due on 1 december

   <trackbot> ACTION-201 Report on status of AWWSW discussions due date
   now on 1 december

   action-278 due 15 october

   <trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to
   cover the "Google Calendar" case due date now 15 october

   <DanC_> action-282: jar says this is his project for the fall

   <trackbot> ACTION-282 Draft a finding on metadata architecture.
   notes added

   action-33 due 15 october

   <trackbot> ACTION-33 revise naming challenges story in response to
   Dec 2008 F2F discussion due date now 15 october

   <DanC_> (larry, is there a draft of HTTPbis which has advice on

   action-232 due in 4 days

   <trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
   of HTTPbis which has advice on conneg due date now in 4 days

   <masinter> (DanC, my proposed revision hasn't been incorporated yet)

   <DanC_> (tx)

   action-232 due on 29 september

   <trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft
   of HTTPbis which has advice on conneg due date now on 29 september

   <masinter> danc


   action-163 due 31 october

   <trackbot> ACTION-163 Coordinate with Ted to build a sample catalog
   due date now 31 october

   discussion of action-295

   noah: Back to the spreadsheet


     [60] http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls

HTML issue: text/html mime type

   <masinter> [61]http://tools.ietf.org/html/rfc2854

     [61] http://tools.ietf.org/html/rfc2854

   lm: RFC2854 is current definition of text/html. written by lm and
   ... history ... mime types are allocated by IETF. Registration at
   top level requires IETF consensus
   ... you designate a change controller. for text/html, it's W3C
   ... I assume that means rec, not a WG last call

   <DanC_> [62]http://www.ietf.org/rfc/rfc2854.txt The 'text/html'
   Media Type

     [62] http://www.ietf.org/rfc/rfc2854.txt

   lm: The proposal in HTML5 is to replace registration with something
   *not* including any history [background]
   ... anything you 'should' need to know is contained in the rec,
   anything else is a bug

   noah: What is typical?

   danc: There be dragons

   lm: It's typical to include history, making updates less of an issue
   ... One reason given is to revoke the permission to serve
   XML-expressed HTML as text/html

   noah: Breaks our agendas and minutes?

   danc: Probably not, since they match the syntax and semantics of

   timbl: The notion that there is an XML language that is an HTML
   language is important as a matter of principle
   ... and that you can serve it as text/html

   noah: The new spec correctly interprets [XHTML] content

   lm: (no...)

   noah: You shouldn't take stuff that's widely deployed and break it

   danc: Depends on what you consider 'widely deployed'

   lm: Purpose of mime type is give an out of band description of what
   the sender intended
   ... It's not normative, it indicates intent

   noah: Self-describing web has a story about answering the question
   "did so and so serve a document x that can be interpreted according
   to such and such interpretation rules" (jar's paraphrase)

   lm: E.g. the profile attribute of head isn't in html5.

   Receiver has no clue what the sender might have meant by a profile

   If the mime type registration doesn't give history, receiver doesn't
   have a chance.

   danc: There is some former-features explanation

   timbl: Safest thing to do might be to make a historical RFC...

   (someone:) how would that help follow your nose?

   ht: At the moment we have hearsay, can we have some references?
   Nothing in the July draft that looks like a mime type
   registration... up to date reference?


     [63] http://dev.w3.org/html5/spec/Overview.html#iana-considerations

   <DanC_> 12.1 text/html

   <ht> What's the issue number for discussion of this?

   [scribe notes that this is not a dated file. may change]

   timbl: Bold and emphasized text - that must be a funny story

   ht: You're now no longer allowed to serve some xml with this label.
   The question is whether reinterpreting as html changes the document
   in any visible way

   <masinter> there were 5 different specifications and languages and
   mulitiple implementations that the previous RFC made reference to...
   these languages were more or less coherent and correlated. Writing
   the history of each element piece by piece is not the same

   danc: table with tr right underneath it - tbody gets implicitly
   added by html at parse time - so different dom

   <DanC_> (hmm... looking for a historical explanation of
   head/@profile, I don't see that, but I see "must not be used by
   authors" with what to do instead; it says "unnecessary; omit it
   altogether, and register the names.")

   lm: there used to be many html versions... the fact that someone
   might meant one of those is lost when you chop it up feature by
   feature. you lose the sense that someone was using a particular
   dialect (language version).
   ... The intent is to outlaw declarations that a document is HTML 4
   ... Rewriting history is absurd. That's what I think the TAG
   response should be

   ht: Is there any precedent for this? Has something like this
   happened before?

   <ht> ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback
   on the text/html media type registration in the 25 September draft
   of HTML5 recorded in [64]http://www.w3.org/2009/09/25-tagmem-irc]

     [64] http://www.w3.org/2009/09/25-tagmem-irc

   <trackbot> Created ACTION-316 - S. to draft for tag@w3.org proposed
   TAG feedback on the text/html media type registration in the 25
   September draft of HTML5 [on Henry S. Thompson - due 2009-10-02].



   <masinter> ... The main thing that needs updating is the removal of
   the permission for sending syntactic profiles of XML as text/html.
   In addition, the encoding considerations, fragment identifier
   definition, and the text about recognising HTML documents are
   somewhat out of date and can be significantly improved by
   referencing HTML5 now. RFC2854 is quite vague in a number of areas,
   also, which can be cleaned up with an update.


   Thomas Roessler is joining us.

   <noahm> The chair thanks Thomas Roessler for joining us on short

   lm: I'm interested in current status. I met with Eve in Stockhom,
   area directors, what is the IETF and Cisco and CDT response?

   tr: I'm not the team contact, this info may be outdated...
   ... Comment was sent by IETF chair
   ... "We are working on the comments, something will be given"
   ... AFAIK they just haven't answered yet

   016.html "We're working on drafting formal responses to the Last
   Call comments we


   <DanC_> have received.

   <DanC_> Unfortunately due to vacations this has been taking a bit
   longer than we

   <DanC_> had expected, but we will have them ready soon."

   <johnk> DanC: I agree with this: Most well-intentioned sites,

   <johnk> and _all_ evil sites (the ones where privacy leakage is an
   issue in the

   <johnk> first place) would just ignore the user's requests

   <johnk> (and evil sites can just put their own code in there to
   ensure that the user's information _is_ leaked)

   <DanC_> suggestion: we've looked at the technical issues and a
   little bit of the policy issues, and come to the conclusion that
   there are several coherent designs and none of them critically in
   conflict with web architecture. Maybe let's action somebody to take
   the remaining liaison/process issues to the IETF/W3C liaison forum
   or something.

   <DanC_> (re orthogonality... the device API WG seems likely to
   persue that approach)

   <johnk> such as [67]http://www.w3.org/2009/policy-ws/cfp.html ?

     [67] http://www.w3.org/2009/policy-ws/cfp.html


     [68] http://www.w3.org/2008/security-ws/report#PolicyDescription

   Adjourned until next time.

Summary of Action Items

   [NEW] ACTION: DanC to follow up on best plan for HTML / TPAC
   recorded in [69]http://www.w3.org/2009/09/25-tagmem-irc]
   [NEW] ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback
   on the text/html media type registration in the 25 September draft
   of HTML5 recorded in [70]http://www.w3.org/2009/09/25-tagmem-irc]
   [NEW] ACTION: John to talk to Balisage participants about XML
   namespace work, discuss TAG interest in this area, and summarize
   recorded in [71]http://www.w3.org/2009/09/25-tagmem-irc]
   [NEW] ACTION: noah Check with Amy on room availability and suggest
   to Ian that he mention this meeting in TAG election call for
   nominations [recorded in

     [69] http://www.w3.org/2009/09/25-tagmem-irc
     [70] http://www.w3.org/2009/09/25-tagmem-irc
     [71] http://www.w3.org/2009/09/25-tagmem-irc
     [72] http://www.w3.org/2009/09/25-tagmem-irc

   [End of minutes]

    Minutes formatted by David Booth's [73]scribe.perl version 1.133
    ([74]CVS log)
    $Date: 2009/10/13 21:41:59 $

     [73] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [74] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 16 October 2009 20:36:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:17 GMT