Meeting record for TAG Telcon: 10th Jan 2008

A draft record of our 10th Jan 2008 meeting is available at: http://www.w3.org/2001/tag/2008/01/10-minutes

Text version below.

Regards

Stuart Williams
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
--------------------------------------------------------------------------------

                               - DRAFT -

                          TAG teleconference

10 Jan 2008

   [2]Agenda

      [2] http://www.w3.org/2001/tag/2008/01/10-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2008/01/10-tagmem-irc

Attendees

   Present
          Stuart, Ht, DanC, Raman, jar, Norm, TimBL, Noah,
          Dave_Orchard, DOrchard

   Regrets
   Chair
          Stuart

   Scribe
          DanC

Contents

     * [4]Topics
         1. [5]Convene
         2. [6]Issue binaryXML-30 (ISSUE-30)
         3. [7]'ping' attribute
         4. [8]Review of "Access Control for Cross-site Requests"
     * [9]Summary of Action Items
     _________________________________________________________



   <scribe> Scribe: DanC

Convene

   SKW: I see regrets TBL 24 Jan

   close ACTION-76

   <trackbot-ng> ACTION-76 Put a bow on the Nov TAG ftf meeing record
   with photos in TAG blog closed

   close ACTION-28

   <trackbot-ng> ACTION-28 draft a blog item for review and, pending
   creation of a TAG blog mechanism, post it. closed

   -> [10]http://www.w3.org/2001/tag/2007/12/13-minutes minutes 13 Dec

     [10] http://www.w3.org/2001/tag/2007/12/13-minutes

   <Zakim> ht, you wanted to mention agenda link

   HT: I added some links to [11]http://www.w3.org/2001/tag/ ... to
   rolling agenda and FTF page

     [11] http://www.w3.org/2001/tag/

   RESOLUTION: to approve minutes 13 Dec

   Next Telcon: Propose 17th January 2008; Chair: Stuart; Scribe DaveO

Issue binaryXML-30 (ISSUE-30)

   -> [12]http://lists.w3.org/Archives/Public/www-tag/2007Dec/0094 Re:
   TAG input to EXI WG on Efficient XML Interchange and EXI
   Measurements [ White 20 Dec ]

     [12] http://lists.w3.org/Archives/Public/www-tag/2007Dec/0094

   HT: read it a while ago... my memory says the discussion is in a
   terminal state

   <scribe> ACTION: ht review EXI WDs since 20 Dec [recorded in
   [13]http://www.w3.org/2001/tag/2008/01/10-minutes#action01]

   <trackbot-ng> Created ACTION-93 - Review EXI WDs since 20 Dec [on
   Henry S. Thompson - due 2008-01-17].

   <ht> DanC, here are the links for my action way higher up:
   [14]http://www.w3.org/TR/exi-primer,
   [15]http://www.w3.org/TR/exi-best-practices

     [14] http://www.w3.org/TR/exi-primer
     [15] http://www.w3.org/TR/exi-best-practices

'ping' attribute

   SKW summarizes HTML 5 ping attribute

   DC: main use case is auditing advertisement links

   <Norm> I'm moved by Roy's arguments against that it's a bad idea.

   TVR: what I know is mostly what was summarized... as to opinion...
   feels like feature creep

   DC: my understanding is that the link auditing is widely practiced,
   using opaque javascript stuff, and that this is more declarative,
   which might allow you to turn it off easier. so I can see some
   benefit to a ping attribute, but I probably wouldn't miss it if it
   went away

   NM: I'm sympathetic to several of the points here... the declarative
   win... RF suggesting the use case hasn't been studied
   sufficiently[?]...

   DanC: some, e.g. JR, object to doing POST on behalf of a user who
   just followed a link, which is widely understood to be a safe
   operation

   ("hyperlink auditing requires use of unsafe HTTP method" ISSUE-1
   PINGPOST [16]http://www.w3.org/html/wg/tracker/issues/1 )

     [16] http://www.w3.org/html/wg/tracker/issues/1

   TBL: use of POST is coherent in that GET might be cached and not
   update a counter.

   (DanC is not convinced; it's not like the world comes to a halt if
   the counter doesn't get updated some small percentage of the time;
   the advertising industry will come up with estimates and norms to
   compensate.)

   <ht> I think Tim's point is a good one, and more general than
   caching -- GET should be repeatable w/o serious consequence, but
   using GET for the ping attr value would seem to contradict that,
   particularly in the advertising logging case. . .

   <timbl> I wonder what other things one get a user to do by making
   them ping a location as an attack

   "When the ping attribute is present, user agents should clearly
   indicate to the user that following the hyperlink will also cause
   secondary requests to be sent in the background, possibly including
   listing the actual target URIs." --
   [17]http://www.w3.org/html/wg/html5/#hyperlink0

     [17] http://www.w3.org/html/wg/html5/#hyperlink0

   DO: I gather the design in the spec doesn't meet real-world
   advertising network requirements.

   SKW reminds us that we re-opened issue whenToUseGet-7 for this
   issue. (ISSUE-7)

   NDW: I also don't find any of the existing use cases compelling; I
   don't see why advertisers would stop using scripts that work for
   them

   discussion of communication from the TAG to the HTML WG shows less
   than a critical mass just yet.

   (issue 7 remains open)

   DO: isn't there a requirements issue about this ping attribute?

   DanC: I'm not sure... checking... no, it looks like not.
   ([18]http://www.w3.org/html/wg/tracker/issues/open )

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

   TVR: perhaps www-tag hasn't been invited to discuss this
   sufficiently
   . ACTION: Noah invite discussion of HTML 5 ping attribute in www-tag
   after some review by tag members

   <scribe> ACTION: Noah invite discussion of HTML 5 ping attribute in
   www-tag after some review by tag members. (html WG mailing list is
   public-html@w3.org ) [recorded in
   [19]http://www.w3.org/2001/tag/2008/01/10-minutes#action02]

   <trackbot-ng> Created ACTION-94 - Invite discussion of HTML 5 ping
   attribute in www-tag after some review by tag members. (html WG
   mailing list is public-html@w3.org ) [on Noah Mendelsohn - due
   2008-01-17].

   NM: OK, yes, I'll bcc public-html and note that I've done so in
   order to avoid cross-posting

   <Noah> I will bcc: public-html, and note in the body of the email
   that I have done so.

Review of "Access Control for Cross-site Requests"

   SKW: Dave and I have sent comments on our own behalf and gotten some
   responses from the editor...

   DO: the WebApp WG was chartered Nov 2005; the access control
   deliverable has come up since then...
   ... the access control work started in [?another wg]. WebApp was
   originally chartered to work on XBL2 and the like...

   <Stuart> s/?other wg/VoiceBrowser WG/ I think.

   DO: the AC hasn't been notified, nor has any requirements document
   been produced.
   ... so a lot of the comments on the design are motivated by
   different implicit requirements
   ... there hasn't been a community requirements discussion
   ... it's a bit awkward to collaborate on this work, because it comes
   up just occasionally between weeks of discussion of XBL2 etc.
   ... my main comments: (1) the browser is effectively a policy
   enforcement point (PEP). Why? It seems to me that the PEP can be
   moved to the server side. cf work by Tyler

   TimBL: oh really? how?

   DO: let's not get into the details of that just now; Tyler has
   proposed a number of designs to meet the server-side-move
   requirement
   ... comment (2) specifying it with an algorithm is awkward; I'd
   rather see definitions that could be met by lots of algorithms
   ... comment (3) they've introduced an authorization request... a GET
   with a Method-check header [?]
   ... the access control spec is silent on the body of the reply to
   that request [?]. this seems architecturally problematic. [scribe
   missed some details... involving SOAP must-understand...]
   ... [something about HEAD and OPTIONS... ]

   TBL: Dave, your point on social process around implicit requirements
   is well made
   ... re moving the PEP to the server side... I'm skeptical... my
   discussion with some mozilla developers convinced me that the
   browser has to enforce these policies in order to protect the user
   [?]

   DO: much of this browser sandbox stuff is obscure; a colleague of
   mine at BEA is an expert in related security work but is struggling
   to get up to speed in this context

   <Zakim> ht, you wanted to point to Jon Ferraiolo's comments which
   support DO

   <ht>
   [20]http://lists.w3.org/Archives/Public/public-appformats/2008Jan/01
   08.html

     [20] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0108.html

   TVR: [somebody else; darn; scribe forgot already] sent comments that
   support DO's position about obscurity of browser sandbox model

   HT: I'm sympathetic to the difficulty of writing this access control
   spec while the browser sandbox model is obscure

   <Zakim> Stuart, you wanted to comment a little on interations with
   WG

   HT: where one would expect to write "change from X to Y" the spec
   has to say "change from whatever it is to Y"

   SKW: the editor is quite responsive, but it's not clear to what
   extent the WG has considered our comments

   noted, ht

   <Zakim> DanC, you wanted to say that what I learned at the W3C
   security workshop is that the browser sandbox models are many and
   changing and obscure on purpose

   <Zakim> Noah, you wanted to say that doing things declaratively is
   more than editorially

   <timbl> There are comments about the way the WG has behaved, the way
   the document is written, and the protocol. These should be clearly
   separately articulated.

   <jar> aren't we saying: a proper technical review requires an
   expression of the criteria against which to evaluate it - and this
   means comprehensive requirements and use cases? so tell us what
   you're trying to do, then we can review?

   (as much as I don't like algorithms either, I haven't heard "more
   than editorial" substantiated.)

   <ht> Here's an example of a more declarative approach to a similar
   spec. problem (allow/deny from apache2):
   [21]http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html

     [21] http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html

   <Zakim> Noah, you wanted to talk about role of TAG

   <Noah> Fropm TAG charter:

   <Noah> The mission of the TAG is stewardship of the Web
   architecture. There are three aspects to this mission:

   <Noah> 1. to document and build consensus around principles of Web
   architecture and to interpret and clarify these principles when
   necessary;

   <Noah> 2. to resolve issues involving general Web architecture
   brought to the TAG;

   <Noah> 3. to help coordinate cross-technology architecture
   developments inside and outside W3C.

   DO: while much of this is process/editorial, the choice of GET [as
   opposed to OPTIONs or HEAD] is technical and architectural

   <Noah> I think that only marginally gives us special status to raise
   an issue like "the spec your workgroup is doing doesn't have clear
   requirements, and is more imperative than we think is wise in
   presenting certain logic"

   (pointer to focussed comment?)

   DanC: I see GET / HEAD / OPTIONS Anne van Kesteren (Friday, 4
   January)
   [22]http://lists.w3.org/Archives/Public/public-appformats/2008Jan/00
   45.html
   ... interesting... "One of our requirements is that you can simply
   put a file on the server and have it work."

     [22] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0045.html

   <dorchard>
   [23]http://lists.w3.org/Archives/Public/public-appformats/2008Jan/00
   92.html

     [23] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0092.html

   DO: in 0092, see "HTTP Method for Authorization Request"

   <Stuart> HTTP Method for Authorization Request
   <Stuart> The specification uses HTTP GET for the Authorization Request, with the
   <Stuart> Method-Check HTTP Request Header. This seems an inappropriate HTTP
   <Stuart> Method because the resource identified by the URI is not being
   <Stuart> dereferenced, rather the intent is to retrieve either Access-Control
   <Stuart> headers or the <?Access-Control?> Processing Instructions. There aren't
   <Stuart> clear requirements that indicate why other HTTP methods such as HEAD or
   <Stuart> OPTIONS aren't used instead or in addition to. I think this is closed
   <Stuart> issue #7, but I'm not sure.

   DanC: in
   [24]http://lists.w3.org/Archives/Public/public-appformats/2008Jan/00
   52.html barstow refers to ISSUE-19; I'm struggling to turn ISSUE-19
   into a full URI
   ... [25]http://www.w3.org/2005/06/tracker/waf/issues/19

     [24] http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0052.html
     [25] http://www.w3.org/2005/06/tracker/waf/issues/19

Summary of Action Items

   [NEW] ACTION: ht review EXI WDs since 20 Dec [recorded in
   [26]http://www.w3.org/2001/tag/2008/01/10-minutes#action01]
   [NEW] ACTION: Noah invite discussion of HTML 5 ping attribute in
   www-tag after some review by tag members. (html WG mailing list is
   public-html@w3.org ) [recorded in
   [27]http://www.w3.org/2001/tag/2008/01/10-minutes#action02]

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [28]scribe.perl version 1.128
    ([29]CVS log)
    $Date: 2008/01/16 15:02:46 $

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

Received on Wednesday, 16 January 2008 15:06:18 UTC