IRC log of tagmem on 2011-03-10

Timestamps are in UTC.

17:59:23 [RRSAgent]
RRSAgent has joined #tagmem
17:59:23 [RRSAgent]
logging to
17:59:36 [Ashok]
zakim, this will be TAG
17:59:36 [Zakim]
ok, Ashok, I see TAG_Weekly()1:00PM already started
17:59:46 [DKA]
zakim, mute me
17:59:46 [Zakim]
DKA should now be muted
17:59:47 [Ashok]
chair: Noah
17:59:53 [DKA]
zakim, unmute me.
17:59:53 [Zakim]
DKA should no longer be muted
17:59:55 [Ashok]
scribe: Ashok
18:00:04 [Ashok]
scribenick: Ashok
18:01:00 [noah]
noah has joined #tagmem
18:01:07 [ht]
ht has joined #tagmem
18:01:10 [JeniT]
hi timbl
18:01:13 [Zakim]
18:01:21 [noah]
Hi Jeni, welcome!
18:01:24 [JeniT]
Zakim, IPcaller is me
18:01:24 [Zakim]
+JeniT; got it
18:01:30 [Zakim]
18:01:31 [noah]
zakim, noah_mendelsohn is me
18:01:32 [Zakim]
+noah; got it
18:01:34 [timbl]
18:01:48 [noah]
zakim, who is here?
18:01:48 [Zakim]
On the phone I see JeniT, DKA, noah, Ashok_Malhotra
18:01:49 [Zakim]
On IRC I see ht, noah, RRSAgent, Zakim, Ashok, DKA, jar_, JeniT, timbl, plinss, jar, trackbot, Yves
18:01:55 [Zakim]
18:02:14 [JeniT]
Thanks Yves
18:02:43 [Larry]
Larry has joined #tagmem
18:02:51 [Zakim]
18:02:57 [timbl]
Zakim, call timbl-office
18:02:58 [Zakim]
ok, timbl; the call is being made
18:03:01 [Zakim]
18:03:05 [Ashok]
present: Dan_Appelquist, Jeni_Tennison, Tim_BL, Noah_Mendelsohn, Jonathan_Rees, Ashok_Malhotra
18:03:06 [johnk]
johnk has joined #tagmem
18:03:25 [noah]
zakim, who is here?
18:03:25 [Zakim]
On the phone I see JeniT, DKA, noah, Ashok_Malhotra, jar, Yves, Timbl
18:03:26 [Zakim]
On IRC I see johnk, Larry, ht, noah, RRSAgent, Zakim, Ashok, DKA, jar_, JeniT, timbl, plinss, jar, trackbot, Yves
18:03:43 [Ashok]
present+: Yves_Lafon
18:03:46 [Zakim]
18:04:00 [ht]
ht has joined #tagmem
18:04:03 [Ashok]
presenr+: Larry_Masinter
18:04:17 [Larry]
18:04:46 [Ashok]
present+: Larry_Masinter
18:05:25 [Larry]
18:05:37 [Ashok]
Topic: Administrative items
18:05:40 [DKA]
+lots welcome Jeni!
18:05:52 [Ashok]
Noah: Welcome, Jeni
18:06:12 [Ashok]
Jeni: Introduction
18:08:04 [Zakim]
18:08:37 [Ashok]
present+: Henry_Thompson
18:09:28 [Ashok]
Noah: Change telcon timings?
18:09:40 [Ashok]
Jeni: I think it will be ok
18:10:11 [Ashok]
Noah: Telcon on March 17
18:10:26 [Ashok]
... I am unavailable
18:10:50 [Larry]
leave meeting scheduled
18:11:11 [DKA]
I am also available next week - and I think it would be useful given the number of things on our docket right now.
18:11:13 [Larry]
if HT can, would go through IETF presentation
18:11:15 [Ashok]
Jar: I can help with the agenda
18:11:25 [ht]
I'm in favour -- hope to have IETF slide deck revised by then
18:11:29 [Ashok]
Ashok: Regrets from me for 3/17
18:11:30 [JeniT]
I can be here
18:11:44 [Larry]
just scheduling review IETF slide deck would be enough to meet
18:12:04 [Ashok]
Noah: Jar will create agenda or cancel
18:12:18 [Ashok]
Larry: We can review Henry's slide deck
18:12:53 [Ashok]
Noah: Dan wanted to discuss f2f timing
18:13:29 [Ashok]
Dan: There is a Socail Web Summit Mtg in Berlin June 4/5. I'm very involved
18:13:42 [Ashok]
... possible conflict
18:13:59 [Ashok]
... could we meet a day later or the follwing week
18:14:23 [ht]
I have 7 June as the start
18:14:27 [ht]
Is that wrong?
18:14:37 [jar_]
i also have 7 june as start...
18:14:45 [jar_]
maybe we both missed something
18:14:46 [Ashok]
Noah: Prefer not to change dates ... Dan may miss first day
18:15:08 [Ashok]
... Tim if you can meet a day later we can move it a day later
18:15:27 [jar_]
ah. so it got changed to the 6th.
18:16:45 [Ashok]
Dan: I can fly directly from Berlin to Boston
18:18:09 [Larry]
q+ to ask to expand topic #4 on this agenda to be IETF meeting topics, including WebApps presentation
18:18:42 [noah]
18:18:44 [DKA]
18:19:19 [Ashok]
Topic: Approve Minutes from 3/3
18:19:28 [Larry]
minutes need s/chamge/change/
18:19:45 [Ashok]
RESOLUTION: Minutes from 3/3 are approved
18:20:21 [Ashok]
Topic: TAG participation in IETF/IAB panel at March 2011 IETF (for March 2011 IETF meeting)
18:20:22 [Larry]
18:20:40 [noah]
close ACTION-535
18:20:41 [trackbot]
ACTION-535 Draft IAB meeting slide on scalability issues. closed
18:20:43 [Ashok]
HT: I will create a new slide deck and we can discuss next week
18:21:03 [noah]
close ACTION-517
18:21:03 [trackbot]
ACTION-517 Figure out what to say about scalability of access at IETF panel closed
18:21:19 [noah]
18:21:19 [trackbot]
ACTION-530 -- Henry S. Thompson to draft slides for IETF meeting, with help from Larry Due 2011-02-22 -- due 2011-02-17 -- OPEN
18:21:19 [trackbot]
18:21:43 [noah]
ACTION-530 Due 2011-03-15
18:21:43 [trackbot]
ACTION-530 Draft slides for IETF meeting, with help from Larry Due 2011-02-22 due date now 2011-03-15
18:22:07 [noah]
18:22:07 [trackbot]
ACTION-527 -- Noah Mendelsohn to make sure we make progress on ACTION-519 and ACTION-517 in time to provide input to Prague IETF meeting, talk to be ready by mid-March -- due 2011-02-17 -- PENDINGREVIEW
18:22:07 [trackbot]
18:22:17 [noah]
close ACTION-527
18:22:17 [trackbot]
ACTION-527 Make sure we make progress on ACTION-519 and ACTION-517 in time to provide input to Prague IETF meeting, talk to be ready by mid-March closed
18:22:32 [Larry]
18:22:33 [noah]
18:23:52 [Ashok]
Larry: There have been discussions at IETF re. Registries etc. Brief mtg Sunday and reference mtg Thursday about Regestries and Mime types, etc.
18:24:11 [Larry]
s/reference mtg/breakfast mtg/
18:24:19 [ht]
I will not be in Prague past Monday night, sorry
18:24:50 [Ashok]
Larry: What does TAG want to happen wrt IANA registeries?
18:25:00 [Larry]
it would be useful to have more of a mandate about what should happen with them
18:26:25 [Ashok]
Noah: Perhaps add Registries to agenda for next week
18:26:56 [Ashok]
Topic: ISSUE-60 (webApplicationState-60): Web Applications: Hash-bang (#!) URIs
18:28:18 [Ashok]
Noah: Ontroduces the topic ... fuss about #! URIs ... some people feel that these have some downsides
18:28:46 [Ashok]
18:29:12 [DKA]
+1 to considering Jeni's post:
18:29:40 [Ashok]
Jeni: People are using #URIs to bookmark application state
18:29:53 [Ashok]
... But # does not go back to the server
18:29:56 [noah]
JT: People are using # URIs; a problem is that they are not sent to the server in cases where you might want them to be
18:30:27 [Ashok]
Jeni: Problem for Serach Engines
18:31:23 [Ashok]
... so they propsed a #! URI ... which converts the #! argument and convert to server params
18:31:46 [Ashok]
... Twitter and Gawker use this
18:32:01 [Ashok]
... problem that JavaScript was not working
18:32:26 [Ashok]
... problem also if Browser does not run JavaScript
18:32:53 [noah]
JT: There problems on various clients with Javascript, including on my Galaxy Tab, some people don't have Javascript, or turn it off. You don't get referrers, and you need Javascript to even see if the resource exists.
18:33:01 [timbl]
I thought that that the js happened to go down on the site was a bit of a reda herring -- site can break in lots of ways -- but the issue of clients without js is a very valid one.
18:33:26 [Ashok]
Jeni: Some architectural disadvantages to this pattern
18:34:20 [noah]
Tim, I strongly agree that relying on Javascript is a big issue, but FWIW Raman seems to disagree. In he says:
18:34:35 [noah]
"at this point, JavaScript is part
18:34:35 [noah]
of the Web platform, and trying to insist that URL references
18:34:35 [noah]
make sense outside a javascript evaluation context does not make
18:34:35 [noah]
sense on today's Web"
18:34:40 [noah]
I find that quite unfortunate.
18:34:59 [noah]
q+ to talk about moving away from #
18:35:05 [Ashok]
Jeni: We need to give some guidance
18:35:06 [Yves]
relying on js is as bad as relying on a specific codec for video, of image format, well, is it that bad? depends on the intended audience
18:35:27 [Larry]
q+ to reiterate pet peeve that the "JavaScript" rules applies to HTML, not to http, not to URIs in general
18:36:17 [jar_]
18:36:39 [Ashok]
Noah: How good or bad is it to rely on JS?
18:36:50 [Larry]
Javascript does not "go from a URI to a representation"
18:36:50 [DKA]
Another datapoint: some webapp development tools, such as Google Web Toolkit, generate hash URIs as a default way to operate - this adds to the problem.
18:37:17 [jar_]
q+ http: is not HTTP (Roy Fielding)
18:37:32 [jar_]
q+ to say http: is not HTTP (Roy Fielding)
18:37:37 [Ashok]
Noah: HTTP does not allow you to send frag id to server ... so no page reload if fragid changes
18:37:56 [Larry]
The definition of HTML is changing to define the # fragment identifier **FOR HTML** to mean (for this content, send # parts to JavaScript)
18:38:05 [Larry]
this deosnt' have anything to do with HTTP actually
18:38:18 [Ashok]
18:38:38 [ht]
I am reminded of "a little bit pregnant" -- that the user experience depends on more than the material directly contained in the response message has been true for a long time
18:38:51 [ht]
Maps? Really?
18:39:25 [timbl]
q+ to say we are on the very of a possibly very complex (or satisfying?) architecture of things, pages, views, points of view, windows, queries, etc.
18:39:49 [noah]
ack next
18:39:51 [Zakim]
noah, you wanted to talk about moving away from #
18:39:56 [Larry]
we've put a lot of effort into an architecture which separates references, content types, and protocols, and am dismayed
18:39:56 [ht]
+1 to TBL (based only on his q+)
18:40:01 [Ashok]
Noah: We shd promote HTML5 facilities that let you send URIs and do not cause page reload
18:40:58 [Ashok]
Larry: We shd not be sloppy about whether what we are discussing applies to HTTP< HTML or applies in general
18:41:34 [noah]
Noah: my main point was that, where the item being referenced is document-like (blog posting, twitter posting, map, etc.) we should assign them non-# URis as we always have. They should work consistently in Ajax and non-Ajax clients as necessary.
18:41:37 [Ashok]
18:41:42 [timbl]
q+ timbl3 to mention (a) that the fragid is a really useful identifier and (b) that the js not being a first clas language on the web is stg which could be reengineered.
18:41:49 [Yves]
not really "sending to js" but fragment processing happen as described in the HTML spec and may also be interpreted by JS present on that HTML page
18:42:16 [jar_]
larry: don't want to lose that [...] orthogonality as we move forward on web architecture
18:42:22 [Yves]
but clearly html's media type definition should be amended (and SVG as well)
18:42:41 [noah]
Ack next]
18:42:46 [Larry]
18:42:47 [noah]
Ack next
18:42:49 [Zakim]
jar_, you wanted to say http: is not HTTP (Roy Fielding)
18:42:52 [Ashok]
Larry: Consider HTML embedded in mail etc. where scripting does not make sense
18:43:08 [Larry]
s/does not make sense/may not be enabled/
18:43:11 [noah]
To me, having a URI that can only be dereferenced at the client and using Javascript, for something as simple as a Tweet, seems very unfortunate.
18:43:57 [Larry]
Noah, that may be unfortunate, but it's a site developer's choice, not an architectural lack
18:44:37 [noah]
Larry, I think our role in the task is to advise those developers on the architectural consequences of the avaialble choices, and for my money, #! is really bad.
18:44:47 [noah]
18:44:49 [noah]
ack next
18:44:52 [Larry]
why is it unfortuante, Noah?
18:44:54 [Ashok]
JAR: How the URI is processed is depending on syntax
18:45:40 [jar_]
why does the uri pattern have to change when we move code from the server to the client or vice versa?
18:45:41 [Larry]
noah, i think we first need to articulate why it is 'bad', i'm having trouble coming up with reasons why it is bad
18:46:27 [DKA]
18:46:53 [Larry]
So there's a picture on page 257 of a book, and all I have is the URI for the book, it's unfortunate that I have to use a fragment identifier to talk about that picture?
18:46:53 [noah]
Seems to me it violates the rule of least power.
18:46:58 [DKA]
q+ to play the mobile card
18:47:09 [noah]
ack next
18:47:11 [Zakim]
timbl, you wanted to say we are on the very of a possibly very complex (or satisfying?) architecture of things, pages, views, points of view, windows, queries, etc.
18:47:26 [Ashok]
Ashok: JS is now ubiquitous
18:47:53 [Ashok]
Tim: Is this the tip of an iceberg?
18:47:54 [JeniT]
If JS were actually ubiquitous, we wouldn't need the #! convention for search engines
18:48:01 [noah]
Larry, it's unfortunate that if you were going to amazon, the name of the book would be
18:48:32 [Ashok]
Ashok: Jeni, JS in the client is ubiquitous
18:48:50 [JeniT]
Ashok, aren't search engines clients?
18:49:07 [Larry]
i'm thinking about the ISO 32000 use case (er, PDF), where you need uri-for-book.pdf#page=257 to access page 257
18:49:10 [noah]
+1 search engines are absolutely clients with respect to the HTTP protocol that's used.
18:49:54 [Larry]
these are locators, not just identifiers
18:50:05 [Larry]
HTTP URIs are locators
18:50:08 [noah]
Larry, I don't think that example is the one that helps settle the case, because even with the traditional non-JS Web you can argue it either way.
18:50:34 [jar_]
timbl: use a language for expressing complex references, don't try to cram all expressiveness into URIs
18:50:42 [Larry]
Noah, I'm not trying to settle the case, just discover some cases
18:50:45 [Ashok]
Tim: #! works but it's a horrible kludge
18:50:45 [noah]
ack next
18:50:47 [Zakim]
timbl3, you wanted to mention (a) that the fragid is a really useful identifier and (b) that the js not being a first clas language on the web is stg which could be reengineered.
18:51:16 [Larry]
does it really have to be "javascript" or just "some scripting language"? Could #! work with Java?
18:51:31 [noah]
q+ to remember rule of least poewr
18:52:36 [Larry]
agree with comments ... just hoping we can be more precise when we're talking about JavaScript vs. when we're talking about "active content" in general
18:53:33 [Ashok]
Tim: Why did Google ask for a static piece why not use a Global Variable?
18:53:33 [noah]
The TAG says []: Principle: Powerful languages inhibit information reuse.
18:53:35 [Yves]
active content that has access to the URI of the document
18:53:47 [Larry]
hypothesis: #! is a way of supplying some additional metadata that isn't otherwise obvious
18:54:05 [noah]
q+ to ask Tim a question
18:54:06 [Larry]
that the URI using #! is not just a locator but is intended as an indexible locator?
18:54:21 [noah]
q+ to remind rule of least power and ask TIm a question
18:54:24 [Larry]
q+ to talk about this hypothesis
18:54:25 [noah]
ack next
18:54:25 [Ashok]
Tim: Making KS a first class object would be a nifty idea!
18:54:35 [JeniT]
18:54:38 [Ashok]
18:55:33 [Ashok]
Yves: The issue is that in the example Gawker they are not exposing a document but an application
18:55:56 [noah]
YL: I think # per se isn't the point. What's happened is that sites like Twitter have gone from exposing linked documents, to exposing a single application that lets you see what would previously have been lots of documents
18:55:56 [Ashok]
... the shift from exposing a document to an app is an application
18:56:18 [Ashok]
... media typ[es need to define fragid semantics
18:56:29 [noah]
Strong +1 to what Yves says about the shift. That's a major loss for the Web, if those "documents" aren't properly linkable.
18:56:37 [Larry]
Noah, so what is the problem with that? Yes, it's an application, no it's not a document. So?
18:56:42 [noah]
ack next
18:56:43 [Zakim]
DKA, you wanted to play the mobile card
18:56:57 [Ashok]
... is #! available for all media types ... lot of things not nailed down ... need to be clarified
18:57:07 [Larry]
They're linkable, just with #!... what's the problem?
18:57:21 [noah]
Larry, just for a start, you can't crawl the links properly. Referrer doesn't work, right. See the whole list Jeni went over of what's broken.
18:57:47 [Yves]
problem is non js aware clients (spiders, etc...)
18:57:48 [noah]
DKA: Javascript or not is not binary. Some device support it in a way you don't want to rely on heavily.
18:58:06 [JeniT]
+1 or sometimes the Javascript support isn't complete
18:58:15 [Larry]
why can't referer (sic) be fixed, then? isn't there some access to history ?
18:58:16 [noah]
DKA: Lots of devices, agents, and other things the reference Web content that do not have Javascript or don't behave as browsers do.
18:58:29 [Yves]
also it breaks in case of redirect
18:58:36 [noah]
DKA: includes things that produce thumbnails.
18:58:42 [Larry]
things that do not have JavaScript do not have HTML5, since HTML5 is an API to the DOM
18:58:48 [noah]
DKA: Car apps that read you tweets
18:59:00 [noah]
ack next
18:59:01 [Zakim]
noah, you wanted to remember rule of least poewr and to ask Tim a question and to remind rule of least power and ask TIm a question
18:59:25 [Larry]
if you want thumbnails or to index HTML you need a javascript interpreter
18:59:51 [DKA]
I like javascript just fine, by the way. Some of my best friends are JavaScript developers.
19:00:04 [Ashok]
Noah: Using JS all the time violates rule of least power
19:00:19 [Larry]
yes, there's a tradeoff when you design your site about whether you want to make people use javascript
19:01:05 [Zakim]
19:01:06 [Ashok]
Noah: JavaScript is a powerful language and perhaps too powerful
19:01:24 [Zakim]
19:01:36 [Larry]
19:01:55 [Larry]
19:02:13 [Ashok]
... asks Tim shd we says JS alwaus is there and use it and if it's not there too bad
19:02:59 [Ashok]
Tim: The rule that you don't reload page ... may go away
19:03:12 [jar_]
a problem is inferring operational behavior from the syntax of the URI. This inhibits URI reuse, since URIs have to change when deployment details change. if method for 'dereference' were decoupled from URI syntax, URIs would be cooler. routing problem.
19:03:23 [Larry]
q+ to talk about architecture that is less judgemental ("#! is bad") and more clearly defining consequences
19:03:54 [noah]
Noah: what I said was, we have published the Rule of Least Power, which says effectively "don't use Javascript, even if it's there, if HTML will do"
19:04:08 [JeniT]
19:04:46 [Larry]
19:04:48 [Ashok]
Tim: When you select an item on the screen it goes on the address bar ... may be from different domains
19:05:35 [JeniT]
It has support in Webkit as well as Firefox I believe
19:05:43 [Ashok]
Tim: Are there any constraints when you do a pushstate()?
19:06:19 [noah]
ack next
19:06:20 [Zakim]
Larry, you wanted to talk about architecture that is less judgemental ("#! is bad") and more clearly defining consequences
19:07:03 [Ashok]
Larry: We will not get a #! is good/bad finding ... we can discuss the consequences
19:07:19 [noah]
We absolutely can say #! is bad in the following ways, and either "don't do it" or "don't do it unless..." Web Arch says things like that all the time.
19:08:18 [Ashok]
... adds some metadata wanting fragid to converted to server-side params
19:08:25 [ht]
q+ to enlarge the issue
19:08:26 [Ashok]
s/to/to be/
19:08:57 [ht]
I don't agree
19:10:05 [JeniT]
q+ to mention distributed applications
19:10:07 [Ashok]
Larry discusses use case where you evolve the app using #
19:11:08 [timbl]
q+ to talk about frames
19:11:56 [noah]
ack next
19:12:07 [noah]
ack next
19:12:08 [Zakim]
ht, you wanted to enlarge the issue
19:12:18 [Ashok]
Noah: The AJAX app would need to create a URI for example for the email you selected
19:13:01 [Ashok]
HT: Focussing on page refressh is too narrow ... there are larger class of issues hidden behind this ... interaction with search engines
19:14:02 [Ashok]
HT: AJAX gave good interactivity but you lost indexing
19:14:20 [Larry]
q+ to ask about adding 'crawlers' to webarch
19:14:40 [noah]
Henry, I hear you, but I don't see how that explains why they went first to # (which I claim is to minimize server interactions) and then #! (which was to get back indexing, given that client limitations forced them to use #)
19:15:09 [Ashok]
HT: We need to think about the various players in the Web world
19:15:42 [Ashok]
... lets brainstorm at next f2f
19:15:45 [noah]
ack next
19:15:46 [Zakim]
JeniT, you wanted to mention distributed applications
19:15:52 [ht]
zakim, bye
19:15:52 [Zakim]
leaving. As of this point the attendees were DKA, JeniT, Ashok_Malhotra, noah, jar, Yves, Timbl, Masinter, ht
19:15:52 [Zakim]
Zakim has left #tagmem
19:15:52 [Ashok]
... I will try and send mail
19:16:14 [Zakim]
Zakim has joined #tagmem
19:16:39 [noah]
19:16:44 [Zakim]
19:16:46 [Ashok]
Jeni: Sometimes the data comes from more than one server
19:16:56 [noah]
q+ timbl
19:17:10 [noah]
ack next
19:18:03 [noah]
ack next
19:18:11 [Larry]
19:18:33 [Ashok]
Yves: An app is a portal that gives you access to information ... it's not one server
19:18:51 [noah]
TBL: I find it frustrating that with Twitter, you're interesting in 140 characters, you have framesets with content coming from another document. You want the inner frame to be associated with what's in the address bar.
19:19:26 [noah]
TBL: I'd like to see someone write the alternative version where you get the Tweet as you want it more or less pure, then the javascript loads and surrounds it.
19:19:51 [noah]
q+ to propose next step for Ashok
19:20:53 [noah]
TBL: In the case Jeni mentions, where an app composes content from several sources, we should push for interoperability not so much at the [id of the state of the app???] level, but at the data interop level.
19:20:57 [Ashok]
Tim: When data comes from several sources we would data interoperability
19:21:47 [noah]
ack next
19:21:48 [Zakim]
noah, you wanted to propose next step for Ashok
19:22:23 [Ashok]
Noah: Next steps on HashInURI
19:22:34 [Ashok]
... several points of view
19:23:30 [Ashok]
... why not summarize different positions and their pros and cons
19:23:51 [Larry]
q+ to argue against setting this up as a 'choice' that we have to make
19:24:06 [DKA]
+1 to merging in some of Jeni's post.
19:27:36 [timbl]
19:28:54 [Larry]
19:29:26 [Ashok]
rrsagent, make logs public
19:29:37 [Ashok]
rrsagent, pointer
19:29:37 [RRSAgent]
19:29:58 [Larry]
definitely want to talk about registries, and IETF presentation on webarch for webapps
19:30:14 [Zakim]
19:30:15 [Zakim]
19:30:15 [Zakim]
19:30:16 [Zakim]
19:30:18 [Zakim]
19:30:19 [Zakim]
19:30:25 [Zakim]
19:30:27 [Zakim]
19:30:29 [Zakim]
TAG_Weekly()1:00PM has ended
19:30:31 [Zakim]
Attendees were DKA, JeniT, Ashok_Malhotra, noah, jar, Yves, Timbl, Masinter, ht