Draft TAG minutes 2011-04-28

Draft minutes from last week's call are now available at

http://www.w3.org/2001/tag/2011/04/28-minutes

...and in plain text below.

Dan

--
              Technical Architecture Group Teleconference

28 Apr 2011

   [2]Agenda

      [2] http://www.w3.org/2001/tag/2011/04/28-agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2011/04/28-tagmem-irc

Attendees

   Present
          Noah Mendelsohn, Dan Appelquist, Jonathan Rees, Peter Linss,
          Jeni Tennison, Henry Thompson, Yves Lafon, Ashok Malhotra,
          Tim Berners-Lee

   Regrets
          Larry Masinter

   Chair
          Noah Mendelsohn

   Scribe
          Dan Appelquist

Contents

     * [4]Topics
         1. [5]Approval of last minutes.
         2. [6]Administrative Items
         3. [7]f2f planning for June
         4. [8]HTML5 authoring
         5. [9]Draft on client side state
         6. [10]Briefly back to f2f
         7. [11]Copyright and Linking
     * [12]Summary of Action Items
     _________________________________________________________

   Noah: Any regrets for next week considering the AC meeting?

   <ht> HT regrets for 18 May

   Ashok: I can scribe next week.

Approval of last minutes.

   Noah: move to approve [13]minutes from last call.

     [13] http://www.w3.org/2001/tag/2011/04/14-minutes

   DKA: RESOLUTION: Minutes from last call approved.

Administrative Items

   Noah: are you at the Privacy workshop, Ashok?

   Ashok: yes. It's just started. Let's discuss next week.

   Noah: Any priorities?
   ... AC meeting in Bilbao. Who will be there?

   DKA: yes I will be there. I will be chairing a panel on mobile
   stuff.

   <ht> Not

f2f planning for June

   Noah: 5+ weeks until f2f.

   <jar_> issue 57

   Noah: What are themes and priorities? Major topics they'd like to
   discuss at f2f? And/or commitments for writing?

   <noah> Jar, are you suggesting issue-57 for F2F?

   <jar_> yes

   <noah> Hi Tim.

   Ashok: I would like the client side state work talked about. I will
   write up something about client side storage.

   JAR: I'm working hard to get a document ready [on issue 57] and we
   should be able to discuss at f2f.

   Noah: How about the copyright and deep linking stuff?

   Jeni: yes.

   DKA: I'd like to "go to last call" on some of these.

   Noah: on copyright and deep linking - we had a broader discussion.
   Then we agreed to work on terminology. But what is success here?
   Should that just be the terminology? Or is that just a first puzzle
   piece?

   JAR: latest draft has gone beyond terminology.

   <noah> Feb F2F [14]http://www.w3.org/2001/tag/2011/02/08-agenda

     [14] http://www.w3.org/2001/tag/2011/02/08-agenda

   Noah: Let's try to use email and teleconferences to focus that over
   the next two weeks.
   ... HTML / XML? We could ask Norm to join us?

   DKA +1

   <ht> +1 to revisiting XML/HTML

   <noah> ACTION: Noah to ask Norm about HTML/XML at June F2F [recorded
   in [15]http://www.w3.org/2011/04/28-tagmem-minutes.html#action01]

     [15] http://www.w3.org/2011/04/28-tagmem-minutes.html#action01

   <trackbot> Created ACTION-548 - Ask Norm about HTML/XML at June F2F
   [on Noah Mendelsohn - due 2011-05-05].

   <noah> ACTION-546?

   <trackbot> ACTION-546 -- Noah Mendelsohn to ask Jim Gettys about
   joining us for lunch at June F2F Due 2011-05-15 -- due 2011-05-17 --
   OPEN

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

     [16] http://www.w3.org/2001/tag/group/track/actions/546

   Noah: I have action-546 which was to get in touch with jim gettys.
   ... roughly: the issue is about the way people are building network
   devices and software to use the lower layer of the TCP/IP stack. TCP
   depends on flow control.
   ... in a network with a bunch of links - one of the hops might be
   slower which can cause things to back up. The way TCP handles this
   is that it depends on packets starting to drop.
   ... TCP notices this and slows down. Problem that Jim has identified
   is that people are building network devices and browsers that are
   buffering too much or generating too much traffic and that can cause
   failure.
   ... he can give the details. Relevance to the tag is questionable.
   Decision is to invite Jim to lunch on Monday the 6th.
   ... Jim did feel that some of this is attributable to a misuse of
   http by user agents. [this could be architectural]

   action-546?

   <trackbot> ACTION-546 -- Noah Mendelsohn to ask Jim Gettys about
   joining us for lunch at June F2F Due 2011-05-15 -- due 2011-05-17 --
   OPEN

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

     [17] http://www.w3.org/2001/tag/group/track/actions/546

   Noah: Jonathan - anything on metadata other than issue-57?

   JAR: Larry and I will get together at end of May to work on it.

   Noah: persistence of references?

   JAR: I'd like to make a decision on that a little later. Nothing new
   right now.

   Noah: Registries - we'll have to ask Larry.
   ... Security and webapp things.

   DKA: Webapps APIs minimization. Also interaction models if I can
   engage with the webapps working group members.

   Noah: Also security and privacy - privacy we should visit next week
   post [workshop]. Security also very important. Any comments?

   JAR: I don't remember how we left John Kemp's draft but we should do
   something with it.

   <Ashok> +1 to JAR suggestion

   <noah> [18]http://www.w3.org/2001/tag/2011/02/security-web.html

     [18] http://www.w3.org/2001/tag/2011/02/security-web.html

   <jar_> wish I had time.

   <noah> [19]http://www.w3.org/2001/tag/2011/02/08-minutes#item02

     [19] http://www.w3.org/2001/tag/2011/02/08-minutes#item02

   <noah> <noah> PROPOSAL: close ACTION-417, and have John publish what
   he's got, slightly cleaned up, as a note with no formal status, but
   at a stable URI. Noah will help.

   <noah> <noah> Larry will help too, and would like this done in time
   for IETF in Prague.

   <noah> ACTION-515?

   <trackbot> ACTION-515 -- Larry Masinter to (as trackbot proxy for
   John) who will publish
   [20]http://www.w3.org/2001/tag/2011/02/security-web.html, slightly
   cleaned up, with help from Noah and Larry -- due 2011-04-12 -- OPEN

     [20] http://www.w3.org/2001/tag/2011/02/security-web.html

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

     [21] http://www.w3.org/2001/tag/group/track/actions/515

   <noah> ACTION-516?

   <trackbot> ACTION-516 -- Noah Mendelsohn to talk with Thomas
   Roessler about organizing W3C architecture work on security -- due
   2011-04-26 -- OPEN

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

     [22] http://www.w3.org/2001/tag/group/track/actions/516

   DKA: Should we talk about #!?

   <Yves> part of client-side state indeed

   Noah: Yes as part of client side state.

HTML5 authoring

   Noah: History goes back 2008. TAG met with HTML working group in
   Mandelieu. Concern that the HTML5 spec was a user agent
   specification, not a language specification...
   ... TAG agreed that it would be fine if HTML group continued with
   the authoring view - [a "view" into the full spec for document
   authors]
   ... "HTML5 Edition for Web Authors"

   <noah> HTML5 Edition for Web Authors

   <noah> [23]http://www.w3.org/TR/2011/WD-html5-20110113/author/

     [23] http://www.w3.org/TR/2011/WD-html5-20110113/author/

   <noah> ACTION-379?

   <trackbot> ACTION-379 -- Noah Mendelsohn to check whether HTML
   language reference has been published -- due 2011-04-26 --
   PENDINGREVIEW

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

     [24] http://www.w3.org/2001/tag/group/track/actions/379

   Noah: we agreed it would be fine if it was taken forward on Rec
   track.
   ... reporting back on action-379. I am satisfied that it is
   happening.
   ... this will be carried forward as a rec track document. I would
   like to close action-379 and move on.

   <noah> closing ACTION-379

   DKA +1 to that it's a big deal and +1 to closing the action

   Noah: Good news.

Draft on client side state

   <noah>
   [25]http://www.w3.org/2001/tag/2011/03/HashInURI-20110331.html

     [25] http://www.w3.org/2001/tag/2011/03/HashInURI-20110331.html

   issue-60?

   <trackbot> ISSUE-60 -- Web Application State Management -- open

   <trackbot> [26]http://www.w3.org/2001/tag/group/track/issues/60

     [26] http://www.w3.org/2001/tag/group/track/issues/60

   <JeniT> I have

   <jar_> I have mostly

   <JeniT> Looked good to me

   Noah: I'm pleased.

   DKA I read it but not at a detailed level.

   Noah: [I think we should change the title.]

   Ashok: Yes. We have a different message now.

   <jar_> liked "you have a control you can move out of the page."

   Noah: You have a reference to Jeni's blog. Is that an appropriate
   long-term reference.

   [I think it's appropriate considering the source]

   <JeniT> You're welcome to copy relevant text

   Ashok: I can take her arguments and summarise them.

   <Yves> ok if it's an informative ref (which it is)

   DKA: Could mirror it in TAG space...

   Noah: We could keep it as a blog reference or paraphrase it in the
   document.

   <jar_> this one, right?
   [27]http://www.jenitennison.com/blog/node/154

     [27] http://www.jenitennison.com/blog/node/154

   <JeniT> yes, that one

   Tim: I think it's good for the TAG to keep stuff in W3C space for
   persistence.

   <jar_> email it to www-archive

   <ht> So we change that sentence to a standard reference, and the
   reference at the end uses a TAG URI and says it's a copy of Jeni's
   blog, with a URI for that too.

   Noah: We haven't often reference in a TAG finding things like
   this...

   <noah> DKA: Jeni could repost on TAG blog

   <noah> NM: Sounds good to me

   DKA: Another option: Jeni re-publishes her entry on the TAG blog.

   <Zakim> ht, you wanted to say yes

   <JeniT> I'm absolutely fine with that, whatever makes it easiest to
   use

   Henry: want to agree with Tim - either put a copy in tag space or do
   what Dan said.

   <Yves> TAG blog entry seems appealing

   Jeni: I'm happy doing anything that's useful. Putting it into the
   TAG blog seems most appropriate. Copying parts of it into the
   document itself might be better, if appropriate.

   <noah> I have no problem linking >both< the original Jeni blog, to
   give credit where it's due, and a W3C blog copy, advertised as
   stable.

   Ashok: level of detail between the two are different. I'd rather
   link to a stable document.

   <noah>
   [28]http://www.w3.org/2001/tag/2011/03/HashInURI-20110331.html#BestP
   ractices

     [28] 
http://www.w3.org/2001/tag/2011/03/HashInURI-20110331.html#BestPractices

   Noah: Last thing - section on Best Practices.
   ... 3 bullets [reads doc]

   <JeniT> +1

   Noah: First bullet - any comments?
   ... second bullet - any comments? this is effectively saying "google
   maps is broken"...

   [some discussion on what google maps does]

   <timbl> Noah: Google maps does the right thing with forward and back

   Jeni: I think it is a bit strong. I think it's going to be up to the
   developer to determine what's appropriate for their application. I
   think it would be strong if it said must but Ok to say "should".

   <noah> Tim, I believe the answer is, that they didn't want to use #,
   because it doesn't work right with non-Javascript clients, and in
   older browsers that precluded updating the address bar

   <Zakim> timbl, you wanted to ask whether there is a good reason for
   that behavior that they don't change the URI at every move

   <Zakim> noah, you wanted to answer Tim

   Tim: Google maps and open street map have this behavior that they
   change your history but don't give you a snapshot in the address
   bar. There are reasons and the TAG document should discuss them.
   Possibly it's distracting? Possibly it's because of leftover issues
   with [older] browsers?

   Noah: Google maps does the right thing if you use the link button to
   get a URI and then email it to someone on a mobile phone that has no
   javascript...

   <noah> TBL: Why are they not doing it now that they can?

   <noah> NM: Good question.

   Tim: Why now, when google maps code is updated regularly, does it
   not [use the API] to change what's in the URL bar?

   Noah: It would leave them in a position where they need 2 user
   interfaces...?

   Tim: But they do that already -

   <JeniT> I suspect it's because the URIs are too complicated to
   generally expose to people

   Noah: we have a recommendation for one way and google does it
   another way - we should understand why they do it that way.

   Ashok: I can ask Raman [ who could talk to us about it ]?

   <noah> I think the question Tim asks is: "Now that more and more
   browsers support the new history API, why does Google Maps still not
   update the address bar on those browsers?"

   Noah: back to the "best practices" - third bullet.
   ... it has advantages / disadvantages for #! ...

   <JeniT> Ashok does say "So far, this works only for Googlebots and
   no one seems to like it."

   Noah: should it make more explicit recommendation?

   Ashok: We can tinker with the wording...

   <JeniT> I don't think it's ok

   DKA: I think we should recommend against it... or at least come down
   slightly in that side.

   <noah> I guess what I'm saying is: using the # leads you to messes
   like #! and kludges like the Google query stuff. It also seems to
   violate specifications.

   Jeni: I think we need to strongly encourage people away from using #
   and #!. But not too strong.

   <JeniT> I said that in the short/medium term it's impractical for
   people not to use #/#!

   <noah> I heard Jeni say that, in the short term, # may be the only
   practical option for some, and we should acknowledge that

   <noah> When something has real architectural problems, I prefer that
   the TAG goes beyond just saying: well, there are pros and cons.

   <Yves> presenting pros and cons and let people decide based on their
   needs is better than say "no"

   <Zakim> jar, you wanted to ask why not consider new mechanisms? e.g.
   using javascript to 'resolve' query URIs

   Ashok: It's a matter of style. What I've tended to do is to say "if
   you use x, these are the benefits and these are the difficulties." I
   am a bit reluctant to stand up and say "&^£*&^@£ don't you do this."
   We should sumamrize the arguments on both sides and stop there.

   <noah> I believe Google maps uses Javascript to resolve query URIS

   <Zakim> noah, you wanted to talk about style

   Ashok: Jonathan what you typed could be a reasonable thing to add.

   Noah: People look to us for architectural guidance. When we think
   something is going to undermine the architectural integrity of the
   Web then we should say that. And I think this is one of those cases.

   <jar_> i.e. the javascript just implements an optimization...
   meaning is constant, implementation is variable

   Noah: I think it's appropriate for the TAG to be a little more than
   dispassionate. The Web is a system that connects people. If people
   violate the specs then it gets fragile.

   <JeniT> +1 *or* we change the normative specs :)

   Noah: if we agree that the world would be better then it's
   appropriate.
   ... Thank you, Ashok. Very significant progress.

   <jar_> ashok, I think it's going well

   <noah> ACTION-481?

   <trackbot> ACTION-481 -- Ashok Malhotra to update client-side state
   document with help from Raman -- due 2011-04-12 -- OPEN

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

     [29] http://www.w3.org/2001/tag/group/track/actions/481

   <noah> ACTION-481 Due 2011-05-10

   <trackbot> ACTION-481 Update client-side state document with help
   from Raman due date now 2011-05-10

   [discussion on where to put it - tag/doc]

   Noah: I would encourage you to move it to /doc earlier rather than
   later. Then every time you want to discuss it spin off a dated copy
   in /doc

Briefly back to f2f

   Tim: We talked about the high-level goals. Could we pick some things
   against which we're prepared to be measured. One of them was
   reviewing HTML5.
   ... We talked about metatdata in general.

   Noah: We need to report to Jeff...
   ... we could do it at the f2f.

   Tim: We could talk off-line [between chairs].

   <timbl> HTML5 review

   <timbl> ARCh of web apps

   Tim: I could take html5 review and arch of webapps [to Jeff].

   <timbl> Core mechanisms of the web

   Noah: I called it "core mechanisms of the Web." e.g. Mime, IRIs,
   etc...
   ... Architecture of webapps is new, html5 is new, but the Web runs
   on other things like http-bis, tcp/ip - we should also be spending
   time on that.

   <ht> I think persistence falls in this category as well

   <timbl> External dependencies of web arch - IRIs, TCP, HTTP bis? DNS

Copyright and Linking

   <timbl> We have to pick 2 or more things -- we can also work outside
   them

   <JeniT>
   [30]http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011
   -04-28.html

     [30] 
http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011-04-28.html

   Jeni: I have edited the introduction to try to reflect previous
   discussion. I would really appreciate any feedback on scope in
   introduction.
   ... things I've done - expanded section on hosting of data in the
   web. and made revisions to section on caching / copying.
   ... structure of the document as a whole. Is that what the group
   wants the document to contain?

   <noah> Tim: on the TAG priorities, it might be worth looking at the
   agenda for the Feb F2F? That indicates where we're putting energy:
   [31]http://www.w3.org/2001/tag/2011/02/08-agenda

     [31] http://www.w3.org/2001/tag/2011/02/08-agenda

   Jeni: what I've tried to do is to identify terminology that's used
   in licenses - how legislation talks about what servers on the web do
   - to be explicit about some of the issues that have been raised to
   the TAG. And then to be explicit about the aims of the document:
   provide an explanation of the way that material is published on the
   web to help inform people writing licenses and legislation

   provide definitions of terms related to web publishing and linking
   that may be useful within licenses and legislation

   describe the technical measures that websites can take to back up
   any restrictions that they place on the use of content they make
   available on the web

   describe the mechanisms by which websites that reuse material can
   ensure they meet the restrictions on the use of that material, for
   example through attribution

   Jeni: appreciate feedback on scope.

   JAR: I think it's great. I like the direction it's going. I'm
   skeptical the attribution mechanism because it borders on giving
   legal advice.

   I support it as well.

   Tim: I support it. There is some question about whether W3C should
   support a policy. I think this document walks the right side of that
   line.

   Noah: I support the document. The document doesn't say but could say
   what the consequences will be to the utility of the Web if certain
   policies were made.

   <timbl> ** Definition of "representation" needs to match or not
   match that given in [webarch].

   Noah: I'm not sure we should do that.
   ... I feel with deep linking, hosting, proxying, etc... we want to
   encourage people who are writing legislation to acknowledge that
   some restrictions that are impractical in order to keep the Web
   going. We do want to say some things along those lines. Explain the
   consequences of restrictions.
   ... The caching is a good example. If you were to pass a law that
   prohibited caching then you should know the web will slow down in
   the following ways or become more expensive in the following ways.
   Another one - a typical use case for the web is that people explore
   what is there in order to find what is there. [in the case of the
   nytimes paywall] you don't know until after you've clicked the link
   that you've used one of your 20 views...

   <Zakim> jar, you wanted to ask whether 'shrink wrap' licenses are in
   scope e.g. legal question is whether american airlines 'do no link
   here' binding => consequence robots/browser

   JAR: This issue goes back to deep linking - a bit different from
   copyright. How broad should this document be? We talked about
   shrinkwrap licenses -licenses that say "you should not link here".

   Jeni: I kind of had that in the back of mind as something to
   mention.

   DKA
   [32]http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011
   -04-28.html#Linking should say that...

     [32] 
http://www.w3.org/2001/tag/doc/publishingAndLinkingOnTheWeb-2011-04-28.html#
Linking

   <noah> To clarify what I said earlier: I think it's really crucial
   that those who pass laws understand how important it is that users
   do not, in general, know where a particular link is going to take
   them, and that it's fundamental to the Web that it should be OK to
   >try< to do a GET on any link. The burden must be on the servers
   hosting the resource to deny access if there is a copyright problem.

   JAR: There's a legal question on whether those contracts are
   binding. We can't answer that but there are consequences / chilling
   effects on innovation.
   ... that's a theme that could be repeated over and over in the
   document.

   DKA +1 to JAR's comments.

   <noah> ACTION-481?

   <trackbot> ACTION-481 -- Ashok Malhotra to update client-side state
   document with help from Raman -- due 2011-05-10 -- OPEN

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

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

   <noah> ACTION-541?

   <trackbot> ACTION-541 -- Jeni Tennison to helped by DKA to produce a
   first draft of terminology about (deep-)linking etc. -- due
   2011-04-26 -- OPEN

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

     [34] http://www.w3.org/2001/tag/group/track/actions/541

   <noah> DKA: I'm happy to work on that aspect of the document

   <ht> Someone thought they ought to say that they don't want you to
   link to it. . .

   <ht> "they" is too diffuse

   <ht> Some of AA undoubtedly _does_ want you to link to their pages

   Tim: the push-back you'll get legally is when there is a site that
   specifically makes its money from advertising and the value of the
   site is only linking to stolen content.
   ... would you also defend the site that links to stolen off-shore
   content?

   <Zakim> noah, you wanted to say where I'd draw the line on linking

   JAR: we can't answer the legal question but we can talk about the
   consequences...

   Noah: There are lots of parts of the law when you presume the it's
   neutral unless there's additional context. E.g. naming someone vs.
   naming someone in the context of [a threat or incitement to
   violence].

   <jar_> "It is the TAG's opinion that" is not the same as "here is
   what's legal or not"

   Noah: illegal because of the way it's used not because of the URI.

   Tim: that's an argument you will come across.

   <jar_> The following legal position would / would not support the
   following technical goal ...

   Noah - I think that is encompassed in the notion of speech.

   <Yves> there are other (and existing) laws for that

   <noah> ACTION-541 Due 2011-05-10

   <trackbot> ACTION-541 Helped by DKA to produce a first draft of
   terminology about (deep-)linking etc. due date now 2011-05-10

   <jar_> noah: The question is intent. Depends on whether someone
   knows what they are saying, when they say a URI

   Noah: Ok - next call in a week. Can we bump the date on your action,
   Jeni?

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Noah to ask Norm about HTML/XML at June F2F [recorded
   in [35]http://www.w3.org/2011/04/28-tagmem-minutes.html#action01]

     [35] http://www.w3.org/2011/04/28-tagmem-minutes.html#action01

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [36]scribe.perl version 1.135
    ([37]CVS log)
    $Date: 2011/05/05 14:30:12 $

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

Received on Thursday, 5 May 2011 14:35:36 UTC