Re: Draft Minutes of the TAG Teleconference of 19 February 2009

I am sorry that I neglected to include the text-only version of these 
draft minutes with my original email.  A copy is attached below.  Thank 


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142



                               - DRAFT -

                              TAG Telcon

19 Feb 2009

   See also: [2]IRC log



          Noah Mendelsohn, Jonathan Rees, David Orchard, Larry
          Masinter, Ashok Malhotra, Henry Thompson, John Kemp, Dan





     * [3]Topics
         1. [4]Approval of Feb 12 Minutes
         2. [5]ISSUE-20 (errorHandling-20):
         3. [6]HTML Working Group asks TAG to consider versioning
         4. [7]Future meetings
     * [8]Summary of Action Items

   jar: Please send link to agenda for f2f

   <johnk> just to note that I cannot scribe next week because I cannot
   attend next week's call (ie. I'm giving regrets for the 26th)

   <DanC> noted, johnk

   LM: I seent msg re. priorities to TAG list.

Approval of Feb 12 Minutes

   Feb 12 Minutes:


   Approved without objection.

ISSUE-20 (errorHandling-20):

   Noah: HT shall we close your action

   <DanC> (ACTION-199 is not done to my satisfaction)

   <DanC> (oops; maybe I'm behind)

   HT: I've marked it pending review. I would rather frame a new, more
   specific, action

   Close ACTION 199

   Noah: Turns over to Larry and Henry

   LM: I've joined HTML WG and gotten into discussions there
   ... if you specify error handling behaviour when does it not become
   an error
   ... Postels law also comes in .. liberal in what you accept ...

   <DanC> Postel's law aka


   LM: interaction between normative text and what people really

   <jar> lm: how you describe languages and protocols from the point of
   view of the participants in it

   LM: how you describe languages and protocols from the pov of
   different participants
   ... 1) what the language is
   ... 2) What a sender shd do?
   ... 3) what shd a receiver do?

   <noah> +1 to Larry's three levels of spec. Though it's premature to
   suggest a TAG finding, I think that could be the core of one.

   ht: I have other perspectives I'd like to add
   ... actually, if that's the right perspective then XML is broken
   ... I'm working on clarifying this thread
   ... perhaps an architectural principle there

   <DanC> (re lmm's 3 things to put in a spec... TimBL and I wrote a
   couple little things like that... I wonder if they ended up cited
   from or incorporated in the W3C manual of style
   [11] )


   ht: Discussion not clear on HTML as it is or it might be. Or XHTML
   or other languages

   <ht> [12]


   ht: some spadework to be done where people are happy and where
   ... Look at above in Firefox. ... it does something interesting with
   invalid XHTML

   <DanC> indeed. ff info page says "application/xhtml+xml"

   <DanC> Content-Length: 1823

   <DanC> Content-Type: application/xhtml+xml

   <DanC> Last-Modified: Thu, 19 Feb 2009 17:24:06 GMT

   First para is valid and displays correctly

   The second para has invalid markup which is flagged with a red box

   scribe: because it's well-formed, it knows boundaries of the problem
   and can brings up the warning box

   <DanC> (ah... no, not cited from W3C manual of style, but found the
   little bits by timbl and myself in the neighborhood of LMM's 3
   things to put in specs: [13] and
   [14] )


   HT: The well-formed but not valid is a good place to stand on

   <jar> compositional semantics: part can be good, part can be not
   good, whole can be partially good

   Raman: When does the fixup happen? Before or after the piece is
   handed to the MathML?

   <johnk> [15] quirks mode
   rendering is relevant


   Raman: where does fixup happen?

   <DanC> care to q+ and elaborate, johnk?

   LM: I'm looking at this in other browsers. Chrome shows nonsense

   HT: Is the principle that the browser shd never fail, 100% sound?

   JohnK: Some interaction with quirks mode rendering of pages ... you
   can get different results by including or not including a XML prolog
   or a DOCTYPE
   ... it's non-deterministic

   <DanC> (sorta interesting that johnk cites
   [16] rather than /TR/html5/
   for a description of quirks mode. when it comes to documenting
   common practice, wikipedia does *remarkably* well.)


   <ht> People may find it worth refreshing


   Noah: Is it good that the browsers never fail? Browsers are just one
   use case

   <johnk> I certainly think that browsers, by design, try to never

   Noah: there are other use cases.

   <DanC> (if noah is claiming that there is no fixup in HTTP parsing,
   I was disillusioned about that in #html-wg a few months ago.)

   Noah: I could get a wrong stock quote ....

   <masinter> want to go deeper into deconstructing "error handling" in

   Noah: mostly its casual use

   <masinter> "Do not fail" vs. "behavior is unspecified" vs "MUST
   signal an error"

   <DanC> (hmm... re humans and web browsing... the security risks are
   materializing at an alarming rate.)

   Noah: I am curious: was Postel's law originally applied to encourage
   receivers to deal with content that was truly broken, or only to
   discourage unnecessary legal variablility on the part of senders.
   E.g. http:// and HTTP:// are both legal, but we might encourage
   senders to be "conservative" and send only the former.

   <johnk> DanC: what is the security risk caused by rendering a
   ("broken") page for a human?

   Noah: was it intended in spirit --- make the best of what shows up?

   LM: It's good to look at stds in other areas ... such as railcars
   and track widths

   <DanC> er... they are legion, johnk... there are all sorts of
   exploits involving different parsing quirks, using white-on-white,
   and what not, no?

   <johnk> ok, got it DanC

   LM: You shd be liberal in what you accept and strict in what you
   ... be as precise as you can.

   Noah: It's a matter of degree.
   ... Postel's law is being used to accept very wierd input

   LM: If your browser accepts stuff that others don't, you get a
   competitive advantage
   ... XML community said it would not do that

   <Zakim> jar, you wanted to talk about feedback to server

   jar: Trying to analyze HTML5 situation and look at other situations
   ... such as balance of power between user and implementer
   ... feedback loop is not tight ... does not support checks and
   balances ... several involved parties
   ... need to take systems approach

   <jar> there's no opportunity for immediate feedback from client to

   <jar> based on what the server just sent. client can't tell server
   "I didn't like that"

   <jar> this is an artifact of the HTTP protocol

   <jar> and it's very unnatural in communication scenarios in nature
   and society

   <johnk> HTTP does allow the server to indicate that it has multiple
   representations of a resource available

   LM: Need to look at various possibilities and decide pros and cons

   <noah> Responding to JAR: in practice, I think some of the feedback
   comes from the fact that most Web site owners test rather carefully
   with various browsers. You're right, though, the protocol itself
   doesn't help, and not all errors get caught in this way.

   Ashok: I didn't get all you said, Larry. Please write mail

   LM: I will write mail

   <masinter> Specifications can't define *everything* for at least two

   <masinter> first is that any actual operational software depends on
   many different subsystems and interfaces that are necessary

   <masinter> DNS, HTTP, URI, etc. not just HTML, the orthogonality of
   specifications requires that any one spec is 'incomplete'

   <johnk> masinter - not everyone seems to agree that specs should be
   orthogonal - can we provide a rationale?

   <masinter> second is that there is a range of possible ways of
   dealing with 'alternatives', including describing them both but
   defining one as preferred, describing one and leaving alternatives
   unspecified, say they are 'error', mandate that receivers *must*
   signal errors, etc.

   <masinter> we should deconstruct error handling and give feedback,
   especially if it's useful for HTML

   Noah: Do we want to keep discussing?
   ... do we need to decided how to followup

   HT: I would like to talk about this at the f2f

   <johnk> +1 to ht: discuss this at f2f

   Noah: Suggestion is we put it down for now and pick up at f2f

   <DanC> I would like to try a bit of polling

   <DanC> poll choices: (a) longstanding error handling principles (b)
   focussed feedback on the HTML 5 spec (and XML?) (c) nominate
   particular msgs in the recent thread (d) offer to do some work

   LM: I think we can make progress here and I would consider working
   on this

   Dan explains poll options

   John: picks a) but worries it may not have impact we desire. Would
   be good to work on other items also

   <dorchard> I prioritize b) and if a) gets done as well, bonus.

   HT: We are not now in position to provide feedback to HTML WG that
   would help. Maybe we can get to that

   Noah: a) without word "longstanding"

   <DanC> (e) use cases

   <johnk> +1 to (e) use-cases

   Noah: We need better usecases

   <DanC> I heard 2 use cases: browses will zillions of users; XML
   systems... [sorta]

   <masinter> Goal is (b). Can do that by selecting (e), and working on
   the subset of (a) that are relevant.

   <noah> NM: If I have to pick from (a)-(d), I'd go for (a), but
   without the prejudice toward principles that are longstanding. Which
   principles are good or bad we'll determine on the merits, and I
   won't be surprised if some of the good ones have a long history.

   Dave: We have to be real-world ... would have been great if we had
   a) done first but ... would rather solve discrete problem

   <noah> NM: What I'd really like to do is help everyone understand
   each others' use cases, and then justify the principles in the
   context of the use cases.

   jar: This is a deep problem ... will require imagination

   <noah> NM: Also, though I didn't say this on the phone, I think that
   there's a lot of thrashing regarding the value and the costs of
   layered specifications vs. integrated specifications, and
   articulating the pros and cons (with use cases) would also be a

   <DanC> model it logically... I'd love to see that, especially
   including the social/economic stuff you hinted at earlier.

   jar: very tough nut to crack ... need to go beyond current thinking

   <DanC> my "that's a PhD thesis, not a TAG issue" muscle is
   twitching, meanwhile.

   Ashok: I would work on a) then apply to b)

   <masinter> "XML is broken because signalling errors doesn't work for

   <masinter> need architecture to combat that viewpoint

   DanC: If Jonathan had intuition on how to model this, I would work
   on it with him

   <jar> ... btw I'm not saying HTML5 is 'wrong'. I'm saying that
   convincing us that they're 'right' if they are is tough - and not
   because we're stupid. We'd have to talk ourselves into it, and we
   haven't figured out how to do that.

   DanC: To get HTML5 spec changed I wd have to convince 15/20 people.
   These people know abt architectural principles
   ... others may benefit from larger discussion

   Noah: Do they agree on architectural principles? E.g. layered
   specifications can be beneficial in supporting reuse and

   <dorchard> I agree with Noah that there is a fundamental
   disagreement about the importance of modular/layered specifications.

   Noah: Many in the HTML5 community seem to feel that the benefits of
   a single integrated specification outweigh the benefits of

   Raman: Passes. Currently I don't see having an impact on HTML5
   ... If I sound negative it's because I gave you actions and I have
   not heard anything

   <DanC> ACTION-226>

   <DanC> ACTION-226?

   <trackbot> ACTION-226 -- Dan Connolly to report at March on tagSoup
   progress since TPAC -- due 2009-02-24 -- OPEN

   <trackbot> [18]


   LM: My goal is to get light on HTML5 Issue

   <noah> Note that Dan agreed to send an email in a few minutes
   clarifying which action he and Tim took that Raman is waiting on.
   I'd assign an action to Dan, but assigning an action to point to an
   action seems bizarre.

   <noah> Thank you, Dan, all set.

   LM: Would be good to deconstruct the ways in which you could
   approach error handling

   <DanC> (I'm now done with my poll; I'm willing to do action-226
   orally now, if the chair/meeting chooses to spend ~10 minutes that

   LM: ... how you create interopeability in web world

   <DanC> EOVERFLOW again, LMM

   LM: I think there are general principles that may apply
   ... do general principles of distributed systems design apply ... or
   is the Web special?

   <masinter> The web *is* different than any other distributed system

   <masinter> and thus W3C TAG is a good place to tease out how the
   architectural principles differ

   JohnK: We shd work on specific usecases and derive general
   principles from them

   <masinter> I don't think it's useful to distinguish between "they"
   and "us"

   Noah: We will discuss further at f2f

   <masinter> as far as what is believed

   Noah: Do we want to discuss this next week?
   ... we will not discuss this next week but followup at f2f

HTML Working Group asks TAG to consider versioning

   <DanC> [19]Ask the TAG to consider HTML in particular in its work on
   versioning on Larry Masinter in the HTML WG


   LM: I told the WG that I would ask to consider this

   Noah: Shall I put this issue into pile of stuff we discuss and
   ... Long history of TAG discussing versioning
   ... need to frame issue in a way that will help it move forward

Future meetings

   Noah: Please send input re. items re f2f agenda

   <DanC> LMM, I recommend
   [20] ->


   Noah: There will be a telcon next week. I will cancel if need be.

   <masinter> DanC the pointer you gave is about uniform access to
   metadata, not about versioning

   <DanC> indeed.

   <DanC> the 2nd technical topic on today's agenda was ISSUE-57
   (HttpRedirections-57) which blurs into metadata

   <DanC> we used all the time on error handling (and versioning a
   little bit) but as Noah was considering a meeting next week, I
   started thinking about whether to pick up metadata and such next

   <DanC> I'd like you to take a look before jar swaps it out

   <DanC> does that make sense?

Summary of Action Items

   [End of minutes]

    Minutes formatted by David Booth's [22]scribe.perl version 1.133
    ([23]CVS log)
    $Date: 2009/02/23 21:03:34 $


Noah Mendelsohn
02/23/2009 04:13 PM
        Subject:        Draft Minutes of the TAG Teleconference of 19 
February 2009

Thanks to our scribe Ashok, draft minutes of the TAG teleconference of 19 
February are available for review at [1].   Unless problems are found, I 
expect to call for approval of these at our face-to-face meeting next 
week.  Thank you.



Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Tuesday, 24 February 2009 19:31:36 UTC