See also: IRC log
<scribe> scribe: Ashok
<scribe> scribenick: Ashok
<DKA> +lots welcome Jeni!
Noah: Welcome, Jeni
Noah: Change telcon timings?
Jeni: I think it will be ok
RESOLUTION: No change in telcon timings
Noah: Telcon on March 17 ... I am unavailable
<Larry> Leave meeting scheduled
<DKA> I am also available next week - and I think it would be useful given the number of things on our docket right now.
<Larry> If HT can, would go through IETF presentation
Jar: I can help with the agenda
<ht> I'm in favour -- hope to have IETF slide deck revised by then
Ashok: Regrets from me for 3/17
<JeniT> I can be here
<Larry> Just scheduling review IETF slide deck would be enough to meet
Noah: Jar will create agenda or cancel
Larry: We can review Henry's slide deck
Noah: Dan wanted to discuss f2f timing
Dan: There is a Social Web Summit Mtg in Berlin June 4/5. I'm very involved
... possible conflict ... could we meet a day later or the following week
Noah: Prefer not to change dates ... Dan may miss first day
... Tim, if you can meet a day later we can move it a day later
Dan: I can fly directly from Berlin to Boston
RESOLUTION: No change in June f2f dates
RESOLUTION: Minutes from 3/3 are approved
<noah> close ACTION-535
<trackbot> ACTION-535 Draft IAB meeting slide on scalability issues. closed
HT: I will create a new slide deck and we can discuss next week
<noah> close ACTION-517
<trackbot> ACTION-517 Figure out what to say about scalability of access at IETF panel closed
<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
<noah> ACTION-530 Due 2011-03-15
<trackbot> ACTION-530 Draft slides for IETF meeting, with help from Larry Due 2011-02-22 due date now 2011-03-15
<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
<noah> close ACTION-527
<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
Larry: There have been discussions at IETF re. Registries etc. Brief mtg Sunday and breakfast mtg Thursday about Registries, Mime types, etc.
<ht> I will not be in Prague past Monday night, sorry
Larry: What does TAG want to happen wrt IANA registeries?
<Larry> it would be useful to have more of a mandate about what should happen with them
Noah: Perhaps add Registries to agenda for next week
Noah: Introduces the topic ... fuss about #! URIs ... some people feel that these have some downsides
<DKA> +1 to considering Jeni's post: http://www.jenitennison.com/blog/node/154
<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
Jeni: # URIs created a problem for Search Engines
... so they proposed a #! URI ... which takes the #! argument and converts to server parameters
... Twitter and Gawker use this
Jeni: Some architectural disadvantages to this pattern
<noah> of the Web platform, and trying to insist that URL references
<noah> sense on today's Web"
<noah> I find that quite unfortunate.
Jeni: We need to give some guidance
<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.
Noah: HTTP does not allow you to send frag id to server ... so no page reload if fragid changes
<Larry> This doesn't have anything to do with HTTP actually
<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
<ht> Maps? Really?
<Zakim> Noah, you wanted to talk about moving away from #
<Larry> We've put a lot of effort into an architecture which separates references, content types, and protocols, and am dismayed ...
<ht> +1 to TBL (based only on his q+)
Noah: We should promote HTML5 facilities that let you send URIs and do not cause page reload
Larry: We should not be sloppy about whether what we are discussing applies to HTTP, HTML or applies in general
<noah> Noah: my main point was that, where the item being referenced is a 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.
<jar_> Larry: don't want to lose that [...] orthogonality as we move forward on web architecture
<Yves> But clearly HTML's media type definition should be amended (and SVG's as well)
<Zakim> jar_, you wanted to say http: is not HTTP (Roy Fielding)
Larry: Consider HTML embedded in mail etc. where scripting may not be enabled
<Larry> Noah, that may be unfortunate, but it's a site developer's choice, not an architectural lack
<noah> Larry, I think our role in the TAG is to advise those developers on the architectural consequences of the avaialble choices, and for my money, #! is really bad.
<Larry> Why is it unfortunate, Noah?
JAR: How the URI is processed is dependent on syntax
<jar_> Why does the URI pattern have to change when we move code from the server to the client or vice versa?
<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
<Larry> So there's a picture on page 257 of a book, and all I have is the URI for the book, is it unfortunate that I have to use a fragment identifier to talk about that picture?
<noah> Seems to me it violates the rule of least power.
<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.
Tim: Is this the tip of an iceberg?
<noah> Larry, it's unfortunate that if you were going to Amazon, the name of the book would be http://amazon.com/#book123
<JeniT> Ashok, aren't search engines clients?
<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
<noah> +1 search engines are absolutely clients with respect to the HTTP protocol that's used.
<Larry> These URIs are locators, not just identifiers
<Larry> HTTP URIs are locators
<jar_> TimBL: Use a language for expressing complex references, don't try to cram all expressiveness into URIs
<Larry> Noah, I'm not trying to settle the case, just discover some cases
Tim: #! works but it's a horrible kludge
Tim: Why did Google ask for a static piece why not use a Global Variable?
<noah> The TAG says [http://www.w3.org/2001/tag/doc/leastPower.html#plp]: Principle: Powerful languages inhibit information reuse.
<Yves> Active content that has access to the URI of the document
<Larry> Hypothesis: #! is a way of supplying some additional metadata that isn't otherwise obvious
<Larry> That the URI using #! is not just a locator but is intended as an indexible locator?
Yves: The issue is that in the example Gawker they are not exposing a document but an application
<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
Yves: the shift is from exposing a document to exposing an application
... media types need to define fragid semantics
<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.
<Larry> Noah, so what is the problem with that? Yes, it's an application, no it's not a document. So?
<Zakim> DKA, you wanted to play the mobile card
Yves: Is #! available for all media types ... lot of things not nailed down ... need to be clarified
<Larry> They're linkable, just with #!... what's the problem?
<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.
<Larry> Why can't referer (sic) be fixed, then? Isn't there some access to history ?
<Yves> Also it breaks in case of redirect
<noah> DKA: Includes things that produce thumbnails.
<noah> DKA: Car apps that read you tweets
<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
Tim: The rule that you don't reload page ... may go away
<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.
Tim: When you select an item on the screen or highlight it, it goes on the address bar ... items may be from different domains
<JeniT> It has support in Webkit as well as Firefox I believe
Tim: Are there any constraints when you do a pushstate()?
<Zakim> Larry, You wanted to talk about architecture that is less judgemental ("#! is bad") and more clearly defining consequences
Larry: We will not get a #! is good/bad finding ... we can discuss the consequences
<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.
Larry: #! adds some metadata wanting fragid to be converted to server-side params
<ht> I don't agree
Larry discusses use case where you evolve the app using #
<Zakim> ht, you wanted to enlarge the issue
Noah: The AJAX app would need to create a URI for example for the email you selected
HT: Focussing on page refresh is too narrow ... there are larger class of issues hidden behind this ... interaction with search engines
... AJAX gave good interactivity but you lost indexing
<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 #)
HT: We need to think about the various players in the Web world
... lets brainstorm at next f2f
<Zakim> JeniT, you wanted to mention distributed applications
HT: I will try and send mail
Jeni: Sometimes the data comes from more than one server
Yves: An application is a portal that gives you access to information ... it's not one server
<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.
<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.
Tim: When data comes from several sources we would focus on data interoperability
<Zakim> Noah, you wanted to propose next steps for Ashok
Noah: Next steps on HashInURI
... several points of view
... why not summarize different positions and their pros and cons
<DKA> +1 to merging in some of Jeni's post.
<Larry> Definitely want to talk about registries, and IETF presentation on webarch for webapps