IRC log of tagmem on 2011-06-06

Timestamps are in UTC.

12:56:54 [RRSAgent]
RRSAgent has joined #tagmem
12:56:54 [RRSAgent]
logging to http://www.w3.org/2011/06/06-tagmem-irc
12:57:01 [ht]
zakim, this is tag
12:57:01 [Zakim]
sorry, ht, I do not see a conference named 'tag' in progress or scheduled at this time
12:57:37 [ht]
scribenick: ht
12:57:40 [Ashok]
Ashok has joined #tagmem
12:57:51 [ht]
meeting: Technical Architecture Group
12:58:17 [ht]
Scribe: Henry S. Thompson
12:58:27 [ht]
Chair: Noah Mendelsohn
12:59:12 [ht]
Agenda: http://www.w3.org/2001/tag/2011/06/06-agenda.html
12:59:31 [ht]
Topic: Agenda review
13:02:01 [ht]
Scribe page: www.w3.org/2001/tag/20011/06/F2FScribing.html
13:03:04 [timbl]
^ http://www.w3.org/2001/tag/20011/06/F2FScribing.html 404 not found
13:03:20 [ht]
s/20011/2011/
13:03:23 [ht]
s/20011/2011/
13:03:28 [Yves]
s/2001/2011/
13:03:33 [timbl]
http://www.w3.org/2001/tag/2011/06/F2FScribing.html
13:04:26 [jar]
jar has joined #tagmem
13:04:28 [ht]
zakim, who is here?
13:04:28 [Zakim]
sorry, ht, I don't know what conference this is
13:04:29 [Zakim]
On IRC I see jar, Ashok, RRSAgent, noah, timbl, Zakim, ht, masinter, JeniT, jeff, DKA, Norm, plinss_, Yves, trackbot
13:04:33 [ht]
zakim, who is on the call?
13:04:33 [Zakim]
sorry, ht, I don't know what conference this is
13:04:35 [Zakim]
On IRC I see jar, Ashok, RRSAgent, noah, timbl, Zakim, ht, masinter, JeniT, jeff, DKA, Norm, plinss_, Yves, trackbot
13:04:58 [timbl]
Zakim, imagine this is a call. There everyone is here in the room.
13:04:58 [Zakim]
I don't understand you, timbl
13:04:59 [ht]
NM: Minutes of 26 May [http://www.w3.org/2001/tag/2011/05/26-minutes] approved
13:05:07 [timbl]
You will, Zakim, you will.
13:05:25 [noah]
http://www.w3.org/2001/tag/products/htmlxmlunification.html
13:06:06 [ht]
NM: I've been moving to using tracker Product pages (above is example) to organize our work on major topics
13:06:25 [ht]
... This is an attempt to move up a level from just using Actions
13:06:40 [masinter]
http://www.w3.org/2001/tag/products/htmlxmlunification.html is lacking standard info for a web page/document: date, author, pointer to context
13:07:00 [masinter]
maybe there should be a "TAG product" template
13:07:18 [ht]
NM: This approach is still novel, and I'm working on expanding and using it
13:07:34 [ht]
... I've added a new feature recently
13:07:51 [ht]
... which allows us to see who is working on what in a single place
13:08:23 [ht]
... ProductAssignments.{xls,pdf}
13:09:10 [ht]
http://www.w3.org/2001/tag/products/assignments
13:10:34 [ht]
NM: Concerned that we are getting into a write-only mode
13:10:36 [masinter]
q+ to talk about giving TAG more power, such as hearing appeals and getting involved early in WG chartering and do more
13:10:51 [ht]
NM: That's better than not writing at all
13:10:59 [ht]
... but we need to do more reading and reviewing
13:11:54 [ht]
NM: JJ has asked many different parts of W3C to come back to him with their two or three main goals for 2011
13:12:26 [ht]
... 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
13:13:26 [ht]
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?
13:13:37 [ht]
Topic: Meeting with Jeff Jaffe
13:13:50 [DKA]
DKA has joined #tagmem
13:14:51 [ht]
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
13:15:02 [ht]
... The TAG is necessarily mostly autonomous
13:15:23 [ht]
JJ: So my request is more about what I hope the TAG will be doing
13:15:37 [ht]
... I like NM's new approach to tracking progress
13:15:45 [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
13:15:54 [ht]
JJ: and I laud the work that's been done already.
13:16:10 [ht]
JJ: The TAG needs to do big things _and_ small things
13:16:22 [ht]
... but be careful not to let too many small things fill all their time
13:17:04 [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.
13:17:08 [DKA_]
DKA_ has joined #tagmem
13:17:09 [ht]
JJ: In strategizing for the W3C, we distinguished between topic areas, such as Privacy, and year-by-year goals, such as having a Workshop
13:17:30 [masinter]
some "small" things can be important, and some "big" things can be unimportant
13:17:59 [ht]
NM: For us, I think that translates as trying to identify some specific areas where we expect to get closure in the current year
13:20:06 [ht]
JJ: I'm very pleased with the most recent TAG Status Report
13:20:29 [ht]
... which stimulated me to think about what I _need_ from the TAG
13:20:56 [ht]
JJ: What's the next thing that's going to challenge our ability to have a clean, standard, Web?
13:21:31 [ht]
JJ: And wrt the fissures we've identified, what can do to fix them?
13:21:36 [noah]
TAG Status report: http://www.w3.org/2001/tag/2011/sum04
13:22:28 [noah]
q?
13:23:23 [masinter]
ack masinter
13:23:23 [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
13:23:26 [timbl]
timbl has joined #tagmem
13:27:59 [ht]
q+ to speculate about how we got blindsided on [...]
13:28:34 [noah]
q+ to respond to Jeff on things like md
13:29:52 [timbl]
q?
13:30:15 [ht]
LM: I wanted to talk about doing more rather than less
13:30:31 [ht]
... important vs. unimportant is better than big vs. little
13:30:47 [ht]
LM: For example, getting involved earlier in chartering discussion
13:31:15 [ht]
... Scoping of WGs is actually crucial to architecture
13:31:31 [ht]
... because the one tends to determine the other
13:31:46 [ht]
... So having multiple WGs with charters to design metadata, for example
13:31:57 [ht]
... leads to multiple metadata mechanisms
13:32:24 [ht]
LM: We have a work item called Metadata Architecture
13:32:40 [ht]
... and trying to produce an overview document
13:32:41 [jar]
q?
13:33:11 [ht]
... but that has been to some extent stalled because we're not involved more directly in the WGs
13:34:15 [ht]
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
13:34:45 [ht]
LM: I want the staff to use us as a resource _before_ things ever get to the AC
13:34:53 [Ashok]
Ashok has joined #tagmem
13:35:00 [timbl]
q+
13:35:06 [ht]
... to help prevent things which cut across web arch in unfortunate ways
13:35:33 [ht]
JJ: The Team using the TAG as a consultant is an interesting idea
13:36:02 [ht]
... but charter content decisions are not always made solely on technical grounds
13:36:12 [noah]
ack next
13:36:13 [Zakim]
ht, you wanted to speculate about how we got blindsided on [...]
13:37:19 [noah]
HT: 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.
13:38:24 [DKA]
DKA has joined #tagmem
13:40:20 [noah]
ack next
13:40:22 [Zakim]
noah, you wanted to respond to Jeff on things like md
13:40:47 [Ashok]
Ashok has joined #tagmem
13:40:55 [ht]
NM: The kind of advice you've asked for opens up something new for us
13:41:33 [jeff]
q+ to find out Noah's 14 other things
13:41:51 [jar]
jar has joined #tagmem
13:43:06 [ht]
NM: We often come up to a wall on certain issues
13:43:23 [ht]
... When to escalate something to you is going to be a hard call for us
13:43:31 [noah]
q?
13:43:35 [noah]
ack next
13:44:13 [noah]
q+ to talk about responsibility without authority
13:44:21 [ht]
TBL: I agree with Larry's (also ?? Brooks's) observation about web arch recapitulating WG structure
13:44:47 [ht]
... So getting involved with the WG chartering thing looks important
13:44:57 [noah]
s/Brooks/Fred Brooks/
13:45:07 [ht]
s/?? //
13:46:08 [ht]
TBL: Looking forward rather than back, we need to find a way to get more engaged tactically
13:46:17 [masinter]
getting the TAG to say things may not be nearly as effective as working directly with the communities otherwise affected?
13:46:35 [DKA]
q?
13:46:37 [DKA]
q+
13:46:37 [noah]
ack next
13:46:40 [Zakim]
jeff, you wanted to find out Noah's 14 other things
13:47:35 [ht]
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
13:48:55 [ht]
q+ to say there are only a few big ones
13:49:24 [ht]
q+ ht2 to point out we won one
13:49:43 [masinter]
q+ to give a different analysis
13:50:21 [noah]
ack next
13:50:22 [Zakim]
noah, you wanted to talk about responsibility without authority
13:50:36 [ht]
JJ: I'm asking the TAG to help me spot major difficulties as early as possible
13:51:26 [ht]
NM: Not sure if we had had this steer three years ago, we would have been able to do anything different
13:53:26 [masinter]
q?
13:53:33 [jar]
q?
13:54:07 [ht]
NM: To a large extent, we have responsibility w/o authority
13:54:52 [ht]
... 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, ...]
13:55:30 [ht]
JJ: And as we can observe, TBL's power is in practice very limited
13:55:56 [noah]
q?
13:57:01 [ht]
JJ: You can't tell me that I don't need what I need -- your ability to effect change is orthogonal to that
13:57:20 [ht]
JJ: I hear that what I'm asking is hard
13:58:17 [Ashok]
q+
14:00:00 [ht]
JJ: 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?"
14:08:41 [DKA]
q?
14:08:50 [timbl]
jar+
14:09:00 [noah]
q?
14:09:06 [noah]
q+ to ask about #!
14:10:44 [masinter]
q+ to ask why staff discussion of metadata architecture is disconnected from TAG discussion of metadata architecure
14:12:49 [noah]
ack next
14:13:32 [ht]
DKA:
14:16:19 [masinter]
wonder if we should have a W3C workshop on metadata architecture
14:17:09 [timbl]
q+ to talk about centralization and social aspects being in scope
14:17:38 [noah]
ack next
14:17:40 [Zakim]
ht, you wanted to say there are only a few big ones
14:18:58 [noah]
ack next
14:18:59 [Zakim]
ht2, you wanted to point out we won one
14:19:34 [ht]
ack next
14:19:36 [Zakim]
masinter, you wanted to give a different analysis and to ask why staff discussion of metadata architecture is disconnected from TAG discussion of metadata architecure
14:20:53 [ht]
LM: If we can identify 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
14:21:09 [ht]
s/If we can identify/There have been/
14:23:13 [noah]
ack next
14:24:19 [ht]
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
14:24:22 [timbl]
q?
14:24:46 [noah]
ack next
14:24:47 [Zakim]
noah, you wanted to ask about #!
14:27:08 [ht]
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.
14:27:48 [ht]
... This would allow me to assign a responsible person to get it moving, give us the opportunity to comment/expand/etc.
14:28:17 [ht]
NM: It would be great to get some early input from JJ as to what he's already aware of
14:28:35 [ht]
JJ: Yes, that sounds like a good idea, but
14:28:57 [ht]
... twice a year is certainly enough, maybe too much
14:29:19 [ht]
... I can live with as long a list as possible, but would urge you to _try_ to make it as small as possible
14:29:44 [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
14:30:25 [ht]
JJ: I'm willing to let you know in advance what I'm focussing on, but I'm somewhat reluctant
14:31:07 [noah]
q?
14:31:11 [ht]
... Because my saying "I'm working on topic X" may be misunderstood, if you think sub-topic X.Y is the new crucial thing
14:31:17 [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.
14:31:17 [noah]
ack next
14:31:21 [masinter]
q?
14:31:26 [ht]
NM: But I'm looking at X.Z
14:33:19 [noah]
ack next
14:33:20 [Zakim]
timbl, you wanted to talk about centralization and social aspects being in scope
14:34:18 [ht]
TBL: Pushing good architecture is necessarily a centralized activity
14:34:57 [noah]
. ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F
14:34:59 [noah]
q?
14:35:00 [ht]
... but what we _want_ is decentralized -- we have to accept that this means being aware of
14:35:01 [masinter]
q+ to push on scheduling workshops on topics with the TAG responsible for documenting architectural findings based on workshop work
14:35:12 [DKA]
q+ just brief comment
14:35:21 [DKA]
q+ to say just a brief comment
14:35:25 [ht]
.. the financial and political is a crucial aspect of architecture
14:35:34 [ht]
... because they drive decentralized activity
14:36:29 [jar]
+1 TBL, this is what I wanted to say. architecture has social and economic goals; can't be "just technical". we favor designs that create and nourish markets, innovation, openness, inclusion
14:36:59 [noah]
. ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F
14:37:00 [masinter]
and that staff should bring TAG in, rather than TAG proposing pushing in
14:38:00 [ht]
TBL: I think a report is too formal, a meeting would be better
14:38:09 [ht]
HST: I'd like to try a report once to see . . .
14:38:48 [ht]
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
14:39:10 [ht]
JJ: We don't need anything new to enable that. . .
14:40:44 [masinter]
i have no objection to Noah doing what Noah proposes, I just don't think it's enough
14:41:05 [noah]
ACTION: Noah to arrange for periodic TAG key issues reports to Jeff per June 2011 F2F Due 2011-10-15
14:41:05 [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].
14:41:48 [noah]
ACTION-563 Due 2011-09-15
14:41:48 [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
14:42:06 [ht]
ack dka
14:42:06 [Zakim]
DKA, you wanted to say just a brief comment
14:42:31 [masinter]
ack masinter
14:42:31 [Zakim]
masinter, you wanted to push on scheduling workshops on topics with the TAG responsible for documenting architectural findings based on workshop work
14:42:34 [DKA]
q?
14:42:42 [ht]
DKA: I also agree that we mustn't ignore the social/financial dimension
14:43:19 [ht]
... just that in the case under discussion, it's difficult to disentangle those from the technical side
14:44:08 [ht]
Topic: ISSUE-60 (webApplicationState-60): Web Applications: Client-side state
14:44:28 [ht]
http://www.w3.org/2001/tag/group/track/issues/60
14:46:23 [ht]
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.
14:46:35 [jeff_]
jeff_ has joined #tagmem
14:47:21 [ht]
DKA: What is the next step, officially?
14:47:57 [ht]
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
14:48:32 [ht]
DKA: Even informally, we could ask for wider review explicitly, beyond just sending to www-tag
14:48:53 [ht]
NM: Ah, JAR points out that we already published TVR's first draft of this as a WD
14:49:58 [noah]
http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20110515.html
14:57:06 [ht]
NM: Review, by sections, march!
14:57:06 [masinter]
q+ to talk about generalizing to all "active content" (e.g., PDF fragment identifiers)
14:58:18 [ht]
NM: Abstract
14:58:18 [noah]
ack next
14:58:21 [Zakim]
masinter, you wanted to talk about generalizing to all "active content" (e.g., PDF fragment identifiers)
14:58:42 [ht]
LM: Active content is the key enabling/context for what we're talking about
14:59:02 [ht]
... We should broaden this prose out to make this clear
14:59:22 [ht]
... HTML + Javascript is common and important, but not the only example
15:00:28 [ht]
... SVG, PDF, even Java
15:00:53 [ht]
NM: Java is different -- there's no document there. . .
15:01:22 [ht]
TBL: Abstracts should cover the entire document, not just the problem statement
15:01:36 [ht]
... So, specifically, include the headline conclusion
15:02:37 [ht]
NM: Should be an Editor's Draft, not a WD (yet)
15:02:43 [ht]
NM: Introduction
15:03:27 [ht]
NM: Doesn't include the comparison between # and other approaches
15:03:47 [ht]
DKA: Needs to be more friendly
15:04:33 [ht]
LM: Strongly disagree with "Fragment identifiers can be used with other protocols such as FTP where they may have different semantics"
15:05:00 [ht]
NM: Protocols _are_ relevant
15:05:53 [ht]
... The protocol is where the use of media type is made explicit
15:06:37 [masinter]
take IMAP for example
15:07:04 [masinter]
if I send you an email with an embedded HTML and it contains fragment identifier relative references, the meaning of the fragement identifier
15:07:16 [ht]
TBL, others: Not protocols
15:07:38 [ht]
JAR: Let's just remove the paragraph
15:07:58 [masinter]
content-type sniffing redefines how media types are used anyway
15:08:39 [masinter]
... the meaning of the fragment identifier is independent of the protocol used to transfer the content, and applies to file: and ftp: as well
15:08:44 [jar]
(that is, remove the paragraph mentioning FTP)
15:08:57 [ht]
NM: Chapter 2
15:09:16 [masinter]
also don't like URI and URL should also say IRI etc.
15:09:25 [ht]
NM: Should be opened up, as for Introduction
15:09:38 [noah]
Section 2 sentence shouldn't just be about fragment id use cases
15:11:28 [ht]
JT: 2.1, table -- are we justified in introducing this new label "Client Parameter" ?
15:12:09 [ht]
NM: Right, these (mostly) mean what they mean, not just client-side
15:12:23 [masinter]
I think the actual use case is a pun -- it is a 'client side parameter' to identify a fragment
15:12:58 [masinter]
just as paths kind of look like file paths, but they're really just arbitrary server side parameter to web server
15:13:57 [ht]
LM: It's an identifier independent of context, but it's _also_ being used client-side as a parameter
15:14:28 [ht]
LM: Similar to path, actually -- just a string, but looks like a file-system path, and is often implemented that way
15:15:00 [masinter]
it's not "client and server" it's "active content" vs. "active services"
15:15:25 [ht]
NM: So need to clarify that this terminology is just for this use case
15:16:10 [noah]
Larry, what about http://example.org/myfile.html#para1
15:16:12 [ht]
LM: Again, this is about active content, for which the fragid is intended
15:17:06 [ht]
... So I'd be happier with 'active content interpreter', rather than 'client'
15:18:03 [ht]
LM: The larger background is the whole move to the hybrid model
15:18:14 [ht]
... With its own security model
15:18:53 [noah]
Larry, what about http://example.org/myfile.html#para1
15:19:07 [ht]
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
15:19:41 [ht]
... It may vary over time
15:19:58 [masinter]
I think text/html now requires javascript and thinking otherwise is just wishful thinking
15:20:03 [ht]
DKA: Or vary per platform
15:20:15 [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
15:21:06 [ht]
----------
15:23:27 [ht]
NM: 2.2
15:24:07 [ht]
TBL: "Retrieving fragments using time ranges (for time fragments) may be done heuristically" -- need to know what the heuristics are based on
15:24:13 [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
15:24:51 [ht]
TBL: And what are they guessing heuristically?
15:24:53 [noah]
TBL: You need to rewrite the mention of heuristic retrieval of video
15:25:08 [masinter]
editorial: section 2.3 uses "URI" and "URL" both
15:25:10 [noah]
TBL: Clarify what sorts of heuristics
15:25:52 [ht]
AM: I'll rewrite the 3rd paragraph
15:25:54 [JeniT]
JeniT has joined #tagmem
15:26:06 [ht]
------------
15:26:10 [ht]
NM: 2.3
15:26:15 [masinter]
wonder if geo: URI scheme is relevant
15:26:25 [noah]
LMM: Section 2.3 para 3 map viewer might confuse people?
15:26:43 [ht]
LM: Map viewer example -- need more history, to explain e.g. why ? wasn't used
15:27:44 [masinter]
Maybe not, would like someone else's review of it. I know too much about PARC map viewer
15:29:13 [ht]
NM: At the point you introduce Google Maps, include that there are _two_ ways to browse:
15:29:28 [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
15:29:30 [ht]
... 1) For full-featured browsing with heavy AJAX;
15:29:54 [masinter]
The GMAIL example is an example of a kind of failure, since the URI isn't uniform, different from the CNN case
15:29:55 [ht]
... 2) Much lighter-weight implementation w/o Javascript (for mobile devices, e.g.)
15:32:05 [masinter]
they're RIs but not URIs
15:32:57 [ht]
LM: Not just not uniform, but context-bound -- of no use outside _your_ mail reader
15:33:10 [masinter]
There's a URI scheme for "mid:" for identifying messages, why didn't GMAIL use that?
15:33:20 [ht]
JT: And this means there are things you lose -- that can be called out
15:34:40 [ht]
NM: Need to get the facts right wrt GMAIL
15:35:05 [masinter]
topic?
15:35:08 [masinter]
agenda?
15:35:31 [ht]
---------
15:35:35 [ht]
NM: 2.4
15:35:54 [ht]
DKA: AJAX/DHTML are not going to mean anything to some readers
15:36:26 [ht]
... Here at least include, maybe replace, but talking about Web Applications with active content
15:37:01 [ht]
NM: I think Web App is worse for our readers
15:37:14 [masinter]
the terminology used here needs to be defined in the introduction
15:37:45 [jar]
http://en.wikipedia.org/wiki/Web_application
15:37:48 [masinter]
the framework that there is active content and web applicaitons
15:37:49 [ht]
NM: Consider a no-JS but refreshing-every-10-seconds clock page -- is this a WebApp?
15:38:13 [ht]
DKA: I'm concerned to keep people from thinking "AJAX? I don't use it, so this isn't relevant to me"
15:39:00 [ht]
LM: So define carefully the whole class at the beginning, then use that class here
15:39:25 [ht]
LM: ... And the intro can include a bit of the history of how DHTML / AJAX figured
15:40:12 [ht]
LM: Some references, here
15:40:19 [ht]
AM: Right, Dojo, for example
15:41:09 [ht]
LM: What is the point of this section -- maybe needs an intro sentence?
15:42:08 [ht]
AM: Doing something like this requires apps to take responsibility for managing state. . .
15:42:57 [ht]
TBL: "Give URIs to everything" can be extended to cover state in active-content, local-updating applications
15:45:16 [ht]
---------------
15:45:20 [ht]
NM: 2.5
15:46:13 [ht]
NM: Web command line
15:46:21 [ht]
is an odd name
15:46:43 [ht]
NM: Parallel with Meta-data in URI
15:47:35 [ht]
TBL: Design of fragid so that it can be usefully typed by users, modified to modify what is returned. . .
15:47:49 [ht]
NM: Change the section title?
15:48:03 [ht]
LM: Expand a bit as well
15:48:40 [ht]
HST: I'm happy to have multiple similar cases
15:48:46 [masinter]
"This is another example of the use pattern ... "
15:48:50 [ht]
YL: These cases are not identical
15:48:59 [masinter]
and give more citations of what these are....
15:49:26 [ht]
YL: In the slidy case there is only one fetch, even as you edit
15:50:46 [ht]
... whereas the others involve multiple fetches
15:50:59 [ht]
HST: Sort of, the two modes of Google Maps, in practice
15:51:05 [ht]
------------
15:51:16 [ht]
NM: So, we will return to this in a later session
15:51:26 [ht]
... I will add a Product page
15:51:39 [ht]
... We may add a second editor
15:52:33 [ht]
Suspended for lunch and informal discussion with Jim Gettys on "Buffer Bloat": http://mirrors.bufferbloat.net/Talks/PragueIETF/
15:52:57 [ht]
RRSAgent, make log world-visible
15:53:04 [ht]
RRSAgent, log?
15:53:04 [RRSAgent]
I'm logging. Sorry, nothing found for 'log'
17:07:16 [jar]
scribe: Jonathan Rees
17:07:20 [jar]
scribenick: jar
17:07:47 [jar]
Jim Gettys finishing up lunchtime presentation
17:08:56 [jar]
TimBL: To what extent should browser UIs expose more of the error messages [possibly connected with latency]?
17:08:58 [masinter]
q+ to wonder about reliance on HTTP for distribution of video and staatic content, vs. e.g., Van Jacobson's Content Aware Networking etc. Is there a way of unloading HTTP traffic for video delivery
17:09:36 [masinter]
buffer bloat should be on TAG list to Jaffe of list of issues for W3C to track? just wondering what TAG does
17:10:26 [jar]
jg: Linux has been putting a timestamp in every TCP packet
17:11:35 [jar]
jg: Hard to determine which hop in a path is the bloated hop
17:12:07 [jar]
timbl: Can we make testing software better?
17:12:24 [jar]
... [for detecting bloat]
17:12:59 [noah]
q?
17:14:13 [jar]
rrsagent, point?
17:14:13 [RRSAgent]
I'm logging. Sorry, nothing found for 'point'
17:14:20 [jar]
rrsagent, pointer?
17:14:20 [RRSAgent]
See http://www.w3.org/2011/06/06-tagmem-irc#T17-14-20
17:15:01 [jar]
jg: See new talk on youtube
17:16:57 [jar]
jg: Now, about web architecture.
17:17:53 [jar]
(Not scribing in detail because text on Jim's slides will do much better than I will)
17:18:40 [jar]
jg: Caching is a big problem, same data being sent millions of times
17:19:02 [jar]
... because encrypted under different keys
17:19:23 [jar]
... CAs have failed
17:20:23 [jar]
... authenticity is independent of location
17:21:37 [jar]
... audio & video over TCP are futile
17:21:44 [masinter]
ack masinter
17:21:44 [Zakim]
masinter, you wanted to wonder about reliance on HTTP for distribution of video and staatic content, vs. e.g., Van Jacobson's Content Aware Networking etc. Is there a way of
17:21:47 [Zakim]
... unloading HTTP traffic for video delivery
17:23:14 [jar]
... telephony and teleconferencing, more particularly - when there's a deadline
17:26:02 [jar]
... TCP is wrong model for web content generally. We have objects that go to many people simultaneously
17:26:15 [Yves]
note draft-burke-content-signature-00.txt
17:26:58 [Yves]
http://www.ietf.org/id/draft-burke-content-signature-00.txt
17:27:24 [jar]
jg: synchronization and centralization make the system fragile
17:29:26 [jar]
... Croquet is VR without centralized coordination
17:30:10 [DKA]
[Apropos to our previous discussion on schema.org: http://tantek.com/2011/155/t6/schemaorg-open-standards-community-must-reject-schema-org]
17:32:26 [jar]
jg: Versions should be nameable
17:33:06 [jar]
... Segments, e.g. image metadata, frames of movies
17:33:57 [JeniT]
"Naming and synchronization in a decentralized computer system." is at http://dspace-test.mit.edu/handle/1721.1/16279
17:34:24 [jar]
... Time should be first class naming system. more recent, next one, deadlines
17:36:06 [jar]
... (this doesn't relate necessarily to buffer bloat)
17:37:02 [jar]
jg: CCNx: all content is signed. everything based on names.
17:37:39 [jar]
... looking at Web on CCNx (replacing HTTP)
17:42:43 [jar]
masinter: How to relate this to our conversation with Jeff, and our upcoming IAB meeting?
17:43:14 [jar]
timbl: Auto fallback to P2P would be nice...
17:43:24 [jar]
jg: Right, that's just what CCNx is about
17:44:28 [jar]
jg: Looking for a more robust caching infrastructure
17:44:54 [jar]
... and also for new naming opportunities
17:47:17 [jar]
... the signature is not in the URI, it's the content that's signed
17:47:35 [masinter]
it's not really 'signature' in that signature requires ownership
17:47:56 [jar]
jg: You're verifying that the content comes from someone who "owns" the URI
17:49:00 [jar]
masinter: You have the problem of finding out who owned a URI 30 years later. Where do the keys come from
17:49:50 [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
17:55:16 [jar]
masinter: More interested in having W3C get an understanding of the problem space, than in diving into paticular possible solutions
17:55:42 [jar]
s/patic/partic/
17:56:29 [jar]
http://www.ccnx.org/
17:57:59 [masinter]
one of the problems with content distribution repair is realizing how much content depends on usage tracking
18:05:32 [jar]
jg: http situation has been made worse by changing tcp initial congestion window from 4 to 10
18:05:59 [jar]
... httpbis has removed the SHOULD
18:06:42 [jar]
masinter: The window advice really depends on context. The right place to put the advice would be an applicability statement
18:08:04 [jar]
jg: the test program to run is netalyzr (see slides)
18:37:24 [jeff_]
jeff_ has joined #tagmem
18:45:00 [jar]
topic: Web Applications: Client-side state
18:48:23 [Larry]
Larry has joined #tagmem
18:48:45 [jar]
(looking at section 3 of document)
18:50:14 [jar]
jt: Security aspect. Mention that there are constraints re which URLs can be pushed into the history
18:51:24 [jar]
noah: Some people have no expectation that the fragid will be meaningful outside the session
18:53:06 [jar]
noah: ... say some URIs are public. there are 2 approaches, either fragid or other parts of URI
18:53:56 [jar]
masinter: 'Public' is the wrong word here. Maybe 'reproducible' states (uniformly identified)
18:54:43 [jar]
... I want to quibble about 'capture'. You design the app so that the state is reproducible
18:55:08 [jar]
... (and identifiable)... it's a design thing, can't be done post hoc
18:56:09 [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.
19:00:40 [jar]
noah: 4 sounds like an endorsement of #! (subtext)
19:00:44 [jar]
jt: "and no one seems to like it" should occur earlier, in section 4
19:01:10 [masinter]
masinter has joined #tagmem
19:01:40 [jar]
noah: Use of word "server" is misleading. Better to say "transmitted" (e.g. email)
19:02:43 [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."
19:02:49 [noah]
Change to say:
19:03:14 [jar]
ht: Copy-paste may be too specific, the more general situation is sending from one place to another (not necessarily on same host/client)
19:03:18 [noah]
Specifically: in "In copy-and-paste situations the entire URI is transmitted."
19:03:53 [jar]
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.
19:04:32 [jar]
ashok: I'll rewrite that sentence
19:05:59 [jar]
ashok: Need to publish soon, so that future tense is appropriate (i.e. before all browsers implement state() methods)
19:06:40 [jar]
noah: Or say that whether this works depends on uptake.
19:07:15 [jar]
jar: Take a more positive attitude, that it seems this is going to be fixed soon (not a "problem" or "unfortunate")
19:09:29 [jar]
noah: Use TAGgy "good practice" boxes?
19:10:39 [jar]
masinter: This is an analysis. Maybe too early to make recommendations.
19:11:38 [jar]
jar: I think "good practice" boxes are mostly pretentious, seem moralistic, prefer more neutral wording
19:11:39 [ht_home]
ht_home has joined #tagmem
19:12:17 [jar]
timbL: Worth distinguishing between local benefit and global benefit. Explain why "should"
19:12:38 [ht]
q+ to niggle about "public" again
19:13:28 [jar]
masinter: Specs talk about compliance. 2119 language is always relative to defining compliance
19:13:47 [Yves]
q+
19:14:02 [jar]
noah: I like 'shoulds'
19:15:25 [jar]
ht: "Public" doesn't belong here [section 5] - too strong - session specificity is OK [?]
19:16:04 [jar]
masinter: It's possible to design apps that identify states or not; if you do it, that's hard, but there are benefits
19:17:38 [jar]
masinter: If section 5 is generally a reprise, it should link back
19:19:06 [jar]
noah: Best practice... app states identified with URIs can be tracked with browser forward/back, and can be shared, etc. etc.
19:19:14 [jar]
(editor now has enough input)
19:19:55 [jar]
yves: "Public" is more nuanced...
19:20:07 [jar]
timbl: Granularity is important.
19:20:16 [jar]
ht: need to choose the granularity that's right
19:21:05 [jar]
noah: Editorially, be consistent about how much reader knows/remembers, either explain all bullets or none
19:22:56 [jar]
jt: back and forward might be events you can catch
19:23:07 [jar]
noah: There's no page reload, right? Isn't that the point?
19:23:18 [jar]
... (on back)
19:24:15 [jar]
... Please verify that whatever the section 5 text says is true
19:27:40 [jar]
(diving into a discussion of google maps whose relevance the scribe fails to grasp)
19:29:27 [jar]
(question: does google maps start with img links to the map tiles, or does are the first tiles loaded by javascript)
19:30:42 [jar]
noah: The only advantage of #! is backward compatibility
19:31:07 [jar]
yves: Twitter is using #! a lot because that makes things easier for server
19:31:15 [noah]
twitter.com/#!abc
19:31:25 [noah]
twitter.com/?id=abc
19:32:32 [noah]
twitter.com/?id=dbc
19:33:05 [jar]
noah: Query case is not good because it forces a page reload
19:33:23 [jar]
yves: Predates the state() API
19:33:38 [noah]
<a href="twitter.com/?id=abc">
19:33:41 [noah]
<a href="twitter.com/?id=bcd">
19:33:47 [noah]
You can get more code reloaded than with
19:33:53 [noah]
<a href="twitter.com/#abc">
19:33:56 [noah]
<a href="twitter.com/#dbc">
19:34:49 [jar]
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
19:35:02 [jar]
noah: Only works for same-page links
19:36:27 [jar]
masinter: Backpointers to earlier section would be nice
19:37:03 [jar]
yves: Don't mention #! in the best practices section
19:37:05 [noah]
LMM: Discuss #! in separate section earlier
19:37:13 [noah]
NM: Strongly agree with Larry
19:37:23 [noah]
HT: Put it in 2.N for some N?
19:37:43 [masinter]
then this section is a summary of previous given best practices
19:37:53 [noah]
YL: Also need to connect to part 6, because #! violates specs
19:38:02 [jar]
Part 6.
19:39:58 [noah]
JAR: I prefer "at variance with" to "violate". You can violate laws, not specs.
19:41:21 [jar]
conflict with?
19:41:31 [jar]
contradict?
19:41:49 [masinter]
need update
19:42:03 [masinter]
I don't even think it's at variance
19:42:22 [masinter]
I think the only thing that needs updating is fragment identifier definition in HTML spec
19:42:48 [jar]
noah: Don't want to convey complacence around these extensions
19:43:32 [jar]
noah: I'm trying to be neutral on whether the apps or wrong, or the specs need updating
19:44:46 [masinter]
this isn't any violation of anything... this is just a normal update
19:46:20 [jar]
ht: For some years, people have been using # in a different way from how it's specified...
19:46:31 [jar]
... [text/html says they identify elements]
19:47:02 [jar]
ht: They're just getting a job done; but it's just a fact that it's different from what the spec says
19:47:40 [jar]
RFC 2854
19:48:54 [jar]
s/says they/says fragids/
19:49:09 [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
19:49:40 [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
19:51:37 [jar]
noah: Get to para 2 more quickly. Punchline: When a representation is text/html, then... "unfortunately"
19:52:48 [jar]
ashok: Should we add this bit about html 5 media type not specifying script-resolved # either?
19:52:58 [jar]
all: yes
19:54:18 [jar]
ht: No, it doesn't belong in a finding, will be outdated
19:54:31 [jar]
s/all:/anonymous:/
19:54:51 [masinter]
we could report that we will have asked HTML5 to fix the bug as soon as we can report it
19:55:01 [jar]
remove 'strictly speaking'
19:55:11 [noah]
http://www.ietf.org/rfc/rfc2854.txt
19:55:15 [noah]
Delete But it works in practice.
19:55:30 [noah]
Delete: strictly speaking
19:56:35 [jar]
jt: I don't think earlier in the doc you talk about the caching aspect. Should be in sec 2, and refer back to it from sec 6
19:57:04 [jar]
jt: There *are* audio and video media types
19:57:08 [noah]
There are audio media types: http://www.iana.org/assignments/media-types/audio/index.html
19:57:26 [jar]
masinter: They're a mess...
19:58:40 [masinter]
media fragments working group is working on a spec to update audio & video media types?
19:59:48 [masinter]
part of the problem is in the draft-masinter-mime-web-info ... that MIME registration template doesn't have a section for describing fragment identifiers and the process doesn't require defining them
19:59:54 [jar]
ashok: Here it's hard to figure out what the secondary resource is, in media fragments
20:01:30 [jar]
noah: If no retrieval is possible, then fragid semantics is unspecified
20:01:55 [jar]
masinter: You can do as you like, but if it's not specified then you won't get reliable communication
20:02:54 [jar]
timbl: Many reasons not to put fragid semantics in registrations
20:04:50 [jar]
ashok: The media fragment spec has a way to say from one time to the next
20:06:58 [masinter]
http://tools.ietf.org/html/rfc3778#section-3
20:07:36 [jar]
noah: (wants declarative URIs)
20:07:48 [masinter]
note definition of application/pdf fragment identifiers as parameters to a "PDFOpen" process
20:08:55 [masinter]
the only problem is that HTML MIME type spec needs an update
20:11:07 [jar]
jar: Can we deal with section 6 after our more general fragid discussion?
20:13:08 [jar]
jt: If you say you want a time chunk, that turns into an http request with a range header
20:14:39 [jar]
jt: Is that practice something we want to bring up in this finding? Does it conflict with any specs?
20:14:53 [jar]
yves: Always a problem since it's a priori processing of the fragment
20:14:56 [masinter]
i'm concerned about taking convention about client/server and turning it into unnecessary normative requirements.
20:15:19 [masinter]
there is no normative requirement for ALL uris that fragment identifiers are not 'sent'
20:15:56 [jar]
... you are saying things about URIs without fetching them...
20:15:59 [masinter]
I'm wondering about linking fragement definition to media type definition needs update
20:18:13 [jar]
ashok: Let's take out the "This document discusses highly..." paragraph
20:18:30 [jar]
ht: Let's not lose the very last sentence of it
20:20:49 [jar]
noah: all media types should specify ids for passive or active as appropriate
20:21:10 [jar]
... swap the two parts
20:21:45 [jar]
noah: delete "when and how ... active content"
20:23:23 [jar]
masinter: Whether or not definitions are directly in media type, or in the document itself...
20:23:35 [jar]
Section 7.
20:24:40 [noah]
http://www.w3.org/2001/tag/products/
20:24:52 [jar]
noah: I started writing a product page... linked from list of TAG product page (NOT IN TRACKER)...
20:27:04 [noah]
http://www.w3.org/2001/tag/products/clientsidestate.html
20:29:53 [jar]
discussion of process around this document
20:35:48 [jar]
consideration of whether and how to take this off of rec track
20:37:12 [jar]
Yves: Suggest we take the WD [from 2009] and publish it as a note, so that it can tombstoned
20:39:15 [jar]
DKA: Having it done or close to done by TPAC would be a good thing
20:40:22 [jar]
noah: TPAC is Nov 1
20:42:38 [jar]
(noah is editing the clientsidestate product page, URL above)
20:47:59 [jar]
topic: Administration
20:49:59 [jar]
summer scheduling
20:50:07 [jar]
TPAC
20:52:50 [jar]
location of sept F2F
20:53:35 [jar]
Congrats to Henry on his promotion
20:56:40 [Ashok]
rrsagent, pointer
20:56:40 [RRSAgent]
See http://www.w3.org/2011/06/06-tagmem-irc#T20-56-40
21:00:29 [jar]
masinter: Regrets for 23 June telcon
21:00:45 [jar]
noah: Regrets for 30 June and 7 July
21:11:16 [jar]
Likely won't meet on June 30, July 7, July 28, Aug 11-25. See spreadsheet
21:19:10 [jar]
discussion of agenda for Tue-Wed
21:23:10 [jar]
noah: There is some ambiguity around whether the TAG has been asked to respond to the HTML-XML TF's draft
21:25:58 [jar]
Adjourned
21:49:16 [jar]
jar has joined #tagmem
22:51:24 [Norm]
Norm has joined #tagmem
22:54:17 [Norm]
Norm has joined #tagmem
23:07:50 [Zakim]
Zakim has left #tagmem
23:49:51 [ht]
ht has joined #tagmem