See also: IRC log
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
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
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
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)
(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
<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)
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