W3C

- DRAFT -

Technical Architecture Group F2F

06 Jun 2011

Agenda

See also: IRC log

Attendees

Present
Dan Appelquist, Tim Berners-Lee, Ashok Malhotra, Larry Masinter, Noah Mendelsohn, Jonathan Rees, Jeni Tennison, Henry S. Thompson
Regrets
Peter Linss
Chair
Noah Mendelsohn
Scribe
Henry S. Thompson, Jonathan Rees

Contents


Agenda review

Scribe page: http://www.w3.org/2001/tag/2011/06/F2FScribing.html

NM: Minutes of 26 May [http://www.w3.org/2001/tag/2011/05/26-minutes] approved

NM: I've been moving to using Product pages (for example: http://www.w3.org/2001/tag/products/htmlxmlunification.html) to organize our work on major topics
... This is an attempt to move up a level from just using Actions

<masinter> http://www.w3.org/2001/tag/products/htmlxmlunification.html is lacking standard info for a web page/document: date, author, pointer to context

<masinter> maybe there should be a "TAG product" template

NM: This approach is still novel, and I'm working on expanding and using it
... I've added a new feature recently
... which allows us to see who is working on what in a single place
... http://www.w3.org/2001/tag/products/ProductAssignment.xls

NM: Concerned that we are getting into a write-only mode
... That's better than not writing at all
... but we need to do more reading and reviewing

Meeting with Jeff Jaffe

NM: JJ has asked many different parts of W3C to come back to him with their two or three main goals for 2011
... We need to do that, bearing in mind that some of our top-level goals are not expected to deliver before the end of the years

TBL: Suppose NM ends up with 6 or a dozen Products, which will be well-described with timetable info -- is that better for you, JJ, than us picking just two or three of them?

JJ: A slight correction to NM's starting point -- I don't view the TAG in quite the same way as other parts of W3C -- I don't have a major role in setting the TAG's priorities
... The TAG is necessarily mostly autonomous
... So my request is more about what I hope the TAG will be doing
... I like NM's new approach to tracking progress

<masinter> I think the TAG is not nearly as effective as it could be, partly because there isn't enough external feedback and requirements from W3C

JJ: and I laud the work that's been done already.
... The TAG needs to do big things and small things
... but be careful not to let too many small things fill all their time

<masinter> i don't think "big" and "small" are the right criteria. There are "important" and "unimportant" and we should try to make sure the TAG is doing important things. Some "small" things can be important, and some "big" things can be unimportant

JJ: In strategizing for the W3C, we distinguished between topic areas, such as Privacy, and year-by-year goals, such as having a Workshop

NM: For us, I think that translates as trying to identify some specific areas where we expect to get closure in the current year

JJ: I'm very pleased with the most recent TAG Status Report
... which stimulated me to think about what I need from the TAG
... What's the next thing that's going to challenge our ability to have a clean, standard, Web?
... And wrt the fissures we've identified, what can we do to fix them?

<noah> TAG Status report: http://www.w3.org/2001/tag/2011/sum04

<Zakim> masinter, you wanted to talk about giving TAG more power, such as hearing appeals and getting involved early in WG chartering and do more

LM: I wanted to talk about doing more rather than less
... important vs. unimportant is better than big vs. little
... For example, getting involved earlier in chartering discussion
... Scoping of WGs is actually crucial to architecture
... because the one tends to determine the other
... So having multiple WGs with charters to design metadata, for example
... leads to multiple metadata mechanisms
... We have a work item called Metadata Architecture
... and trying to produce an overview document
... but that has been to some extent stalled because we're not involved more directly in the WGs

JJ: Charter drafts go to the AC for review, the TAG could request from the AB that the TAG should be a virtual AC rep for those purposes

LM: I want the staff to use us as a resource before things ever get to the AC
... to help prevent things which cut across web arch in unfortunate ways

JJ: The Team using the TAG as a consultant is an interesting idea
... but charter content decisions are not always made solely on technical grounds

HST: History is complicated. Illustrative in one respect. The TAG got involved, made suggestions to the WG, worked hard and in detail 2 years. There came a point at which we concluded that we had done what we could.

NM: The kind of advice you've asked for opens up something new for us
... We often come up to a wall on certain issues
... When to escalate something to you is going to be a hard call for us

TBL: I agree with Larry's (also Fred Brooks's) observation about web arch recapitulating WG structure
... So getting involved with the WG chartering thing looks important
... Looking forward rather than back, we need to find a way to get more engaged tactically

<masinter> getting the TAG to say things may not be nearly as effective as working directly with the communities otherwise affected?

JJ: NM asserted there were many cases where the TAG stopped after making the technical point, despite (or because) not having succeeded in changing things

JJ: I'm asking the TAG to help me spot major difficulties as early as possible

NM: Not sure if we had had this steer three years ago, we would have been able to do anything different
... To a large extent, we have responsibility w/o authority
... Our only authority is indirect, via TBL's presence on the TAG, and is the ultimate arbiter of what goes forward [to REC, as a WG, ...]

JJ: And as we can observe, TBL's power is in practice very limited
... You can't tell me that I don't need what I need -- your ability to effect change is orthogonal to that
... I hear that what I'm asking is hard
... The TAG could say "There are 10 things we see that might require the CEO's attention -- which of these did you know about already?"

<timbl> jar+

<masinter> wonder if we should have a W3C workshop on metadata architecture

LM: There have been places where the Team are discussing a topic, and the TAG have something on the go in that area, without making the connection -- we should try harder to avoid that in future

AM: Rigo Wenning compared the TAG to the European Human Rights Commission -- no formal authority, but a lot of influence, because they produce well-written, well-thought out analyses

NM: One thing we might do, two -- four times a year, is to prepare a written note to JJ with a consensus view of what we thing might need your attention.
... This would allow me to assign a responsible person to get it moving, give us the opportunity to comment/expand/etc.
... It would be great to get some early input from JJ as to what he's already aware of

JJ: Yes, that sounds like a good idea, but
... twice a year is certainly enough, maybe too much
... I can live with as long a list as possible, but would urge you to try to make it as small as possible

<masinter> I'd rather see W3C management/staff ask the TAG for help in bringing an architectural perspective to issues; I'm not sure the TAG is the right canary to raise warnings about topics

JJ: I'm willing to let you know in advance what I'm focussing on, but I'm somewhat reluctant
... Because my saying "I'm working on topic X" may be misunderstood, if you think sub-topic X.Y is the new crucial thing, but what I'm actually looking at is X.Z

<masinter> TAG started some architectural work on security, and we're struggling with how to make progress on that with the upcoming W3C work on security and IETF etc.

<Zakim> timbl, you wanted to talk about centralization and social aspects being in scope

TBL: Pushing good architecture is necessarily a centralized activity

TBL: but what we want is decentralized -- we have to accept that this means being aware that
... the financial and political is a crucial aspect of architecture
... because they drive decentralized activity

<jar> +1 TBL, this is what I wanted to say. The architecture has social and economic goals; can't be "just technical". We favor designs that create and nourish markets, innovation, openness, inclusion

<masinter> and that staff should bring TAG in, rather than TAG proposing pushing in

TBL: I think a report is too formal, a meeting would be better

HST: I'd like to try a report once to see . . .

LM: I don't think the TAG is a very good canary -- better to have the Team come to us with problem aras they would like our input on

JJ: We don't need anything new to enable that. . .

<masinter> i have no objection to Noah doing what Noah proposes, I just don't think it's enough

<noah> ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 [recorded in http://www.w3.org/2001/tag/2011/06/06-minutes.html#action01]

<trackbot> Created ACTION-563 - Arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 [on Noah Mendelsohn - due 2011-06-13].

<noah> ACTION-563 Due 2011-09-15

<trackbot> ACTION-563 Arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 due date now 2011-09-15

<Zakim> masinter, you wanted to push on scheduling workshops on topics with the TAG responsible for documenting architectural findings based on workshop work

DKA: I also agree that we mustn't ignore the social/financial dimension
... just that in the case under discussion, it's difficult to disentangle those from the technical side

ISSUE-60 (webApplicationState-60): Web Applications: Client-side state

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

NM: I've reviewed this from end-to-end, I'm concerned that some of the new material is not consistent with the earlier, introductory material.

DKA: What is the next step, officially?

NM: If it's a finding, there is no 'officially'. If we go to REC track for this, then yes, we have to go through the usual hoops

DKA: Even informally, we could ask for wider review explicitly, beyond just sending to www-tag

NM: Ah, JAR points out that we already published TVR's first draft of this as a WD

<noah> http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110515.html

NM: Review, by sections
... Abstract

<Zakim> masinter, you wanted to talk about generalizing to all "active content" (e.g., PDF fragment identifiers)

LM: Active content is the key enabling/context for what we're talking about
... We should broaden this prose out to make this clear
... HTML + Javascript is common and important, but not the only example
... SVG, PDF, even Java

NM: Java is different -- there's no document there. . .

TBL: Abstracts should cover the entire document, not just the problem statement
... So, specifically, include the headline conclusion

NM: Should be an Editor's Draft, not a WD (yet)

NM: ---------- Introduction
... Doesn't include the comparison between # and other approaches

DKA: Needs to be more friendly

LM: Strongly disagree with "Fragment identifiers can be used with other protocols such as FTP where they may have different semantics"

NM: Protocols are relevant
... The protocol is where the use of media type is made explicit

<masinter> take IMAP for example---if I send you an email with an embedded HTML and it contains fragment identifier relative references, the meaning of the fragment identifier is independent of the protocol used to transfer the content, and applies to file: and ftp: as well

TBL, others: Not protocols

JAR: Let's just remove the paragraph

<jar> (that is, remove the paragraph mentioning FTP)

<masinter> content-type sniffing redefines how media types are used anyway

NM: ---------- 2

<masinter> also don't like URI and URL should also say IRI etc.

NM: Should be opened up, as for Introduction

<noah> Section 2 sentence shouldn't just be about fragment id use cases

JT: 2.1, table -- are we justified in introducing this new label "Client Parameter" ?

NM: Right, these (mostly) mean what they mean, not just client-side

<masinter> I think the actual use case is a pun -- it is a 'client side parameter' to identify a fragment just as paths kind of look like file paths, but they're really just arbitrary server side parameter to web server

LM: It's an identifier independent of context, but it's also being used client-side as a parameter
... Similar to path, actually -- just a string, but looks like a file-system path, and is often implemented that way

<masinter> it's not "client and server" it's "active content" vs. "active services"

NM: So need to clarify that this terminology is just for this use case

LM: Again, this is about active content, for which the fragid is intended
... So I'd be happier with 'active content interpreter', rather than 'client'
... The larger background is the whole move to the hybrid model
... With its own security model

<noah> Larry, what about http://example.org/myfile.html#para1

NM: In moving to active content, do need to note that you can't tell by inspection whether a fragid is going to be actively interpreted
... It may vary over time

DKA: Or vary per platform

<masinter> I think text/html now requires javascript and thinking otherwise is just wishful thinking

<noah> Ashok, it's crucial you point out that you can't tell from the URI whether the fragment is interpreted by active content and that the answer might change on successive retrieval

NM: ---------- 2.2

TBL: "Retrieving fragments using time ranges (for time fragments) may be done heuristically" -- need to know what the heuristics are based on

<masinter> not sure the map viewer example might just confuse people... might need more context, e.g., that it was done before the "?" pattern was done, before web forms

TBL: And what are they guessing heuristically? You need to rewrite the mention of heuristic retrieval of video, to clarify what sorts of heuristics.

<masinter> editorial: section 2.3 uses "URI" and "URL" both

AM: I'll rewrite the 3rd paragraph

NM: ---------- 2.3

<masinter> wonder if geo: URI scheme is relevant

LMM: Section 2.3 para 3 map viewer might confuse people?

LM: Map viewer example -- need more history, to explain e.g. why ? wasn't used

<masinter> Maybe not, would like someone else's review of it. I know too much about PARC map viewer

<masinter> example in document of https://mail.google.com/mail/?shva=1#inbox/12c7e6abbc328af4 doesn't resolve to anything for me... doesn't explain how some URIs aren't really "Uniform", in that they don't carry application state in an interesting way

NM: At the point you introduce Google Maps, include that there are two ways to browse:

NM: 1) For full-featured browsing with heavy AJAX;

NM: 2) Much lighter-weight implementation w/o Javascript (for mobile devices, e.g.)

<masinter> The GMAIL example is an example of a kind of failure, since the URI isn't uniform, different from the CNN case: they're RIs but not URIs

LM: Not just not uniform, but context-bound -- of no use outside your mail reader

<masinter> There's a URI scheme for "mid:" for identifying messages, why didn't GMAIL use that?

JT: And this means there are things you lose -- that can be called out

NM: Need to get the facts right wrt GMAIL

NM: ---------- 2.4

DKA: AJAX/DHTML are not going to mean anything to some readers
... Here at least include, maybe replace, that talking about Web Applications with active content

NM: I think Web App is worse for our readers

<masinter> the terminology used here needs to be defined in the introduction

<masinter> the framework that there is active content and web applicaitons

<jar> http://en.wikipedia.org/wiki/Web_application

NM: Consider a no-JS but refreshing-every-10-seconds clock page -- is this a WebApp?

DKA: I'm concerned to keep people from thinking "AJAX? I don't use it, so this isn't relevant to me"

LM: So define carefully the whole class at the beginning, then use that class here
... ... And the intro can include a bit of the history of how DHTML / AJAX figured
... Some references, here

AM: Right, Dojo, for example

LM: What is the point of this section -- maybe needs an intro sentence?

AM: Doing something like this requires apps to take responsibility for managing state. . .

TBL: "Give URIs to everything" can be extended to cover state in active-content, local-updating applications

NM: ---------- 2.5
... Web command line is an odd name

NM: Parallel with Meta-data in URI

TBL: Design of fragid so that it can be usefully typed by users, modified to modify what is returned. . .

NM: Change the section title?

LM: Expand a bit as well

HST: I'm happy to have multiple similar cases

<masinter> "This is another example of the use pattern ... "

<masinter> and give more citations of what these are....

YL: These cases are not identical

YL: In the Slidy case there is only one fetch, even as you edit
... whereas the others involve multiple fetches

HST: Sort of, the two modes of Google Maps, in practice

NM: So, we will return to this in a later session
... I will add a Product page
... We may add a second editor

Buffer bloat and Web architecture

Meeting adjourned for lunch and informal discussion with Jim Gettys on "Buffer Bloat": http://mirrors.bufferbloat.net/Talks/PragueIETF/

Afternoon scribe: Jonathan Rees

Jim Gettys is finishing up his lunchtime presentation (no scribe during lunch).

TimBL: To what extent should browser UIs expose more of the error messages [possibly connected with latency]?

<masinter> buffer bloat should be on TAG's list to Jaffe of issues for W3C to track? just wondering what TAG does

jg: Linux has been putting a timestamp in every TCP packet.
... It's hard to determine which hop in a path is the bloated hop.

timbl: Can we make testing software [for detecting bloat] better?

jg: See new talk on youtube [scribe: probably "Bufferbloat: Dark Buffers in the Internet" - which talks about tools]

jg: Now, moving on to Web architecture.

(I'm not scribing in detail because text on Jim's slides will do much better than I will.)

jg: Caching is a big problem. The same data being sent millions of times
... because it's encrypted under different keys.
... CAs have failed.
... Authenticity is independent of location.
... Audio & video over TCP are futile.

<Zakim> masinter, you wanted to wonder about reliance on HTTP for distribution of video and static content, vs. e.g., Van Jacobson's Content Aware Networking etc. Is there a way of

jg: Telephony and teleconferencing, that is, more particularly - interactions where there's a deadline.
... TCP is the wrong model for Web content generally. We have objects that go to many people simultaneously.

<Yves> note http://www.ietf.org/id/draft-burke-content-signature-00.txt

jg: Synchronization and centralization make the system fragile.
... Croquet is VR without centralized coordination [scribe: http://c2.com/cgi-bin/wiki?OpenCroquet]

<DKA> [Apropos to our previous discussion on schema.org: http://tantek.com/2011/155/t6/schemaorg-open-standards-community-must-reject-schema-org]

jg: Versions should be nameable.
... So should document segments, e.g. image metadata, frames of movies.

<JeniT> "Naming and synchronization in a decentralized computer system." [D. Reed 1979] is at http://hdl.handle.net/1721.1/16279

jg: Time should be a first class naming system. More recent, next one, deadlines, etc.
... CCNx (http://www.ccnx.org/): all content is signed. Everything is based on names.
... We're looking at doing Web on CCNx (replacing HTTP).

masinter: How to relate this to our conversation with Jeff, and our upcoming IAB meeting?

timbl: Auto fallback to P2P would be nice...

jg: Right, that's just what CCNx is about
... Looking for a more robust caching infrastructure
... and also for new naming opportunities
... the signature is not in the URI, it's the content that's signed

<masinter> it's not really 'signature' in that signature requires ownership

jg: You're verifying that the content comes from someone who "owns" the URI

masinter: You have the problem of finding out who owned a URI 30 years later. Where do the keys come from?

<masinter> I think it's not necessary to solve the problems of identity in order to solve the problem of reliability of content delivery through unreliable channels.

masinter: I'm more interested in having W3C get an understanding of the problem space, than in diving into particular possible solutions

<masinter> one of the problems with content distribution repair is realizing how much content depends on usage tracking

jg: The HTTP situation has been made worse by changing the TCP initial congestion window from 4 to 10
... HTTPbis has removed the SHOULD

masinter: The window advice [in HTTP spec] really depends on context. The right place to put the advice would be an applicability statement.

jg: The test program to run is netalyzr (see slides)

ISSUE-60 (webApplicationState-60): Web Applications: Client-side state (continued)

(group review of section 3 of Ashok's draft)

jt: Security aspect: Mention that there are constraints re which URLs can be pushed into the history.

noah: Some people have no expectation that the fragid will be meaningful outside the session
... say some [?] URIs are public. there are 2 approaches, either fragid or other parts of URI

masinter: 'Public' is the wrong word here. Maybe 'reproducible' states (uniformly identified)
... I want to quibble about 'capture'. You design the app so that the state is reproducible
... (and identifiable)... it's a design thing, it can't be done post hoc.

<noah> Propose: As discussed above, JavaScript applications can choose to capture public, reproducible states using URIs, either by varying the fragment identifiers, or when modern browser interfaces are available, by altering URI query strings or path segments.

noah: 4 sounds like an implicit endorsement of #! (subtext)

jt: "and no one seems to like it" should occur earlier, in section 4

noah: Use of word "server" is misleading. Better to say "transmitted" (e.g. could be via email)

<noah> Specifically: in "In copy-and-paste situations the entire URI is sent to the server and the server can decide, based on the client's capabilities, how to respond."

<noah> Change to say:

<noah> Specifically: in "In copy-and-paste situations the entire URI is transmitted."

ht: Copy-paste may be too specific, the more general situation is sending from one place to another (not necessarily on same host/client)

ht: You email me a URI containing a #. I'm going to put it into a tool and the server won't get the fragid.

ashok: I'll rewrite that sentence
... We need to publish this soon, so use of future tense is appropriate (i.e. we'll publish before all browsers implement state() methods)

noah: Or say that whether this works depends on uptake.

jar: Take a more positive attitude, that it seems this is going to be fixed soon (not a "problem" or "unfortunate")

noah: Use TAGgy "good practice" boxes?

masinter: This is an analysis. Maybe too early to make recommendations.

jar: I think "good practice" boxes are mostly pretentious. They seem moralistic, I prefer more neutral wording

timbL: It's worth distinguishing between local benefit and global benefit. Explain why "should".

masinter: Specs talk about compliance. 2119 language is always relative to defining compliance

noah: I like 'shoulds'

ht: "Public" doesn't belong here [section 5] - too strong - session specificity is OK [?]

masinter: It's possible to design apps that identify states or not; if you do it, that's hard, but there are benefits.

masinter: If section 5 is generally a reprise, it should link back to the earlier sections.

noah: Best practice... application states that are identified with URIs can be tracked with browser forward/back, and can be shared, etc. etc.

(The editor is expressing that he now has enough input.)

yves: "Public" is more nuanced...

timbl: Granularity is important.

ht: need to choose the granularity that's right

noah: Editorially, be consistent about how much the reader knows or remembers. Either explain all bullets or none

jt: Back and forward might be browser events you can catch

noah: There's no page reload, right? Isn't that the point?
... (on back)
... Please verify that whatever the section 5 text says is true

(diving into a discussion of google maps whose relevance the scribe fails to grasp)

(question: does a google maps page start with IMG links to the map tiles, or are the first tiles loaded by javascript?)

noah: The only advantage of #! is backward compatibility

yves: Twitter is using #! a lot because that makes things easier for server

<noah> twitter.com/#!abc

<noah> twitter.com/?id=abc

<noah> twitter.com/?id=dbc

noah: Query case is not good because it forces a page reload

yves: #! predates the state() API

<noah> <a href="twitter.com/?id=abc">

<noah> <a href="twitter.com/?id=bcd">

<noah> You can get more code reloaded than with

<noah> <a href="twitter.com/#abc">

<noah> <a href="twitter.com/#dbc">

timbl: Within the page id=abc, for non js browsers, you have a link to id=abc, but you put an onclick even that intercepts

noah: Only works for same-page links

masinter: Backpointers to earlier section would be nice

yves: Don't mention #! in the best practices section

<noah> LMM: Discuss #! in separate section earlier

<noah> NM: Strongly agree with Larry

<noah> HT: Put it in 2.N for some N?

<masinter> then this section is a summary of previous given best practices

<noah> YL: Also need to connect to part 6, because #! violates specs

Part 6.

<noah> JAR: I prefer "at variance with" to "violate". You violate laws, not specs.

conflict with?

contradict?

<masinter> need update

<masinter> I don't even think it's at variance

<masinter> I think the only thing that needs updating is fragment identifier definition in HTML spec

noah: Don't want to convey complacence around these extensions
... I'm trying to be neutral on whether the apps are wrong, or the specs need updating

<masinter> this isn't any violation of anything... this is just a normal update

ht: For some years, people have been using # in a different way from how it's specified...
... [text/html says fragids identify elements]
... They're just getting a job done; but it's just a fact that it's different from what the spec says

RFC 2854

<masinter> my view is that the new use of fragment identifiers to identify application is not a "violation" or a "conflict" but merely an evolution which hasn't tracked

<masinter> the specs *are* being updated, and the only unfortunate thing is the dumb power struggle which is getting in the way of getting the documents updated quickly

noah: Get to para 2 more quickly. Punchline: When a representation is text/html, then... "unfortunately"

ashok: Should we add this bit about html 5 media type not specifying script-resolved # either?

anonymous: yes

ht: No, it doesn't belong in a finding, such a statement will be outdated [quickly].

<masinter> we could report that we will have asked HTML5 to fix the bug as soon as we can report it

<jar> remove 'strictly speaking'

<noah> http://www.ietf.org/rfc/rfc2854.txt

<noah> Delete But it works in practice.

<noah> Delete: strictly speaking

jt: I don't think that earlier in the document you talk about the caching aspect. It should be discussed in section 2, and then section 6 should refer back to it.
... There are audio and video media types, by the way.

<noah> There are audio media types: http://www.iana.org/assignments/media-types/audio/index.html

masinter: They're a mess...

<masinter> media fragments working group is working on a spec to update audio & video media types?

<masinter> part of the problem is in the draft-masinter-mime-web-info ... that [the] MIME registration template doesn't have a section for describing fragment identifiers and the process doesn't require defining them

ashok: Here it's hard to figure out what the secondary resource is, in media fragments

noah: If no retrieval is possible, then fragid semantics is unspecified

masinter: You can do as you like, but if it's not specified then you won't get reliable communication

timbl: There are many reasons not to put fragid semantics in registrations.

ashok: The media fragment spec has a way to say from one time to the next

<masinter> http://tools.ietf.org/html/rfc3778#section-3

noah: (wants declarative URIs)

<masinter> note definition of application/pdf fragment identifiers as parameters to a "PDFOpen" process

<masinter> the only problem is that the HTML MIME type spec needs an update

jar: Can we deal with section 6 after our more general fragid discussion?

jt: If you say you want a time chunk, that turns into an http request with a range header
... Is that practice something we want to bring up in this finding? Does it conflict with any specs?

yves: That's always a problem since it's a priori processing of the fragment

<masinter> i'm concerned about taking a convention about client/server and turning it into unnecessary normative requirements.

<masinter> there is no normative requirement for ALL uris that fragment identifiers are not 'sent'

yves: you are saying things about URIs without fetching them...

<masinter> I'm wondering about linking fragement definition to media type definition needs update

ashok: Let's take out the "This document discusses highly..." paragraph

ht: Let's not lose the very last sentence of it

noah: all media types should specify ids for passive or active as appropriate
... swap the two parts
... delete "when and how ... active content"

masinter: Whether or not definitions are directly in media type, or in the document itself...

(Now look at section 7.)

<noah> http://www.w3.org/2001/tag/products/

noah: I started writing a product page... linked from list of TAG product page (NOT IN TRACKER)...

<noah> http://www.w3.org/2001/tag/products/clientsidestate.html

discussion of process around this document

consideration of whether and how to take this off of rec track

Yves: I suggest we take the WD [from 2009] and publish it as a note, so that it can tombstoned

DKA: Having the document done or close to done by TPAC would be a good thing

noah: TPAC is Nov 1

(noah is editing the clientsidestate product page, URL above)

Administration

summer scheduling

TPAC

location of sept F2F

Congrats to Henry on his promotion

masinter: Regrets for 23 June telcon

noah: Regrets for 30 June and 7 July

Likely won't meet on June 30, July 7, July 28, Aug 11-25. See spreadsheet

discussion of agenda for Tue-Wed

noah: There is some ambiguity around whether the TAG has been asked to respond to the HTML-XML TF's draft

Adjourned

Summary of Action Items

[NEW] ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15 [recorded in http://www.w3.org/2001/tag/2011/06/06-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/06/21 13:24:47 $