TAG f2f -- 26 Mar 2010

Agenda review/rework

NM: Application morning, rest in afternoon?
... Approved

Web Application Architecture: Taxonomy of Web Application Structures

<DanC_> ACTION: John to edit ftf minutes day 1 (Wednesday 24 March) [recorded in http://www.w3.org/2001/tag/2010/03/26-minutes.html#action01]

<trackbot> Created ACTION-415 - Edit ftf minutes day 1 (Wednesday 24 March) [on John Kemp - due 2010-04-02].

JK: http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy.html
... http://www.w3.org/2001/tag/2010/03/web-apps-taxonomy/web-apps-taxonomy.html

<DanC_> ACTION-352?

<trackbot> ACTION-352 -- John Kemp to integrate whiteboard drawings into a prose document about ways to distribute applications -- due 2010-03-08 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/352

JK: This is a transcription of the whiteboard from last time
... Ways of acquiring and using web applications
... 1) Widget-style: download compressed packaged widget, install, run on client via widget platform
... Weak form of trust between widget and widget platform, by means of crypto signatures
... Trust often proxied by use of an 'app-store'

JK: 2) Server-side collection, install and run from server

<DanC_> (I wonder why iGoogle isn't in the document. I think it's good to start with concrete things that people know before abstracting.)

NM: Two versions? Really all CGI on server, completely ignorant client, vs. Javascript into client which reflects widget structure

AM: Widgets execute independently, or can they pass info back and forth?

JK: To some extent

TVR: iGoogle has a limited facility

JK: Limited Javascript sometimes used, e.g. Caja
... Security and trust is the main thrust of this investigation

In (2), DNS-based trust, that is, you trust the owner of the server-side container, iGoogle, or Facebook, for example

<DKA> Apache wookie is a good open source implementation of w3c widgets in the context of running in a web page: http://incubator.apache.org/wookie/

JK: 3) Client-side dynamic mashup
... Locus of cross-site scripting vulnerabilities
... One site creates content including e.g. Javascript which requests to other sites
... Content assembled on the client, based on multiple sources
... Restricted by same-site, CORS, etc.
... Trust based on combination of implicit user grant, same-origin policy, others
... Tabulator?

TBL: Yes

DA: Specifically referring to the WARP spec.?

<DKA> http://www.w3.org/TR/widgets-access/

DA: Adds another security policy in this space

DA: Relevant to installed widgets

<Zakim> DanC_, you wanted to noodle on (a) using this to review HTML 5 origin and perhaps the origin header draft and (b) think about audiences... webapps wg, the group around

<DanC_> Widget Access Request Policy W3C Working Draft 08 December 2009

DC: Origin stuff also in HTML5, do these interact?
... Learned by writing code

TVR: Like everyone else

DC: What about the origin header?

NM: I think we could produce, for a similar audience to webarch, a document with scenarios such as the ones is these diagram

<timbl> http://mashssl.org/

AM: a problem in this scenario [client-side dynamic Mash-up] is establishing trust between Website A and Website B... there's an interesting technology for that ... mashssl

<timbl> "THE STANDARD FOR ESTABLISHING TRUST IN MULTI-PARTY WEB APPLICATIONS."

AM: I was very impressed with this

TVR: You could do this with OAuth

<timbl> "Many modern web application protocols require applications to communicate with each other through a user's browser. But what if the user is malicious or the user's browser has malware?"

TBL: Friend in the middle -- does not trust the user

TVR: iGoogle uses OAuth to function as that kind of middle-man

<DanC_> (I've seen this mashssl page, but I can't tell when... I don't see it in http://delicious.com/connolly . I haven't studied it far enough to tell how it works)

<noah> From Mashssl.org:

<noah> When two web applications are communicating through a user's browser, for instance to provide the user a mashup, the applications do not have a standard and secure method of authenticating each other and establishing a secure channel. In addition to the risk of MITMs (man-in-the-middle) between the user and one of the web applications, there is the additional, potentially bigger, risk of a malicious user. We motivate this problem with a very simple thought ex

<timbl> http://mashssl.org/technology_mashssl.html

<timbl> https://www.safemashups.com/downloads/MashSSL_Towards_Multi_Party_Trust_in_the_Internet.pdf

<timbl> ^ White paper

<jar> AFAICT mashssl is a conventional ACL approach, completely opposite Caja.. thus the usual vulnerabilities

JK: But that's still delegated user authorization, via a middleman
... not the same as trust between middleman and third-party as such

DC: Thinking about audiences -- where are we wrt talking with/to/hearing from the WebApps WG?
... and the public-web-security security mailing list

<DanC_> http://lists.w3.org/Archives/Public/public-web-security/

<DanC_> http://www.w3.org/Security/wiki/Main_Page

NM: next steps? Divide up writing?

TVR: Divide up the space first, then get ownership

NM: Do that, for sure, but prefer doing it after we talk about URIs and Identification

TVR: Worried we will be left with no-one assigned to write

DC: Leaving at 2, prefer to know who owns what during discussion

NM: Tech Discuss first, vs divvy first
... 2 vs. 2

TBL: add me to Divvy first

NM: Agreed

TVR: Time-bound

NM: Bound to an hour, return after lunch to URIs etc.
... While discussing divvy, need to cover what constitutes success, who is the audience, table of contents

Framing/Dividing up further work on Web Applications

TVR: I did this work on # in URIs last year, that's just a small part
... The large question of Web Applications needs a broad scope
... Data plus interaction working via web technologies
... Yes, even Flash
... My preference is for HTML, CSS and Javascript
... but there are lots of others -- anything that comes over HTTP(S)
... How does this become 'live' in your memory -- the DOM

<noah> I personally would say: yes Flash, when the intention is to use it in a Wed-arch compatible way (he says circularly). Flash is Turing-complete, and I don't want to talk about everything it could do.

TVR: plus eventing, javascript interpretation, then more web access
... which in turn requires authentication, trust, so we loop back into the beginning

<DanC_> (transport being HTTP/HTTPS... how about websockets? XMPP? and SMTP comes in for email callback auth)

TVR: This breaks down into four or five documents, which I think we should divide up responsibility for and try to develop

<johnk> I deliberately ignored the "browser plugin" model in the web-apps taxonomy

NM: I heard TVR to suggest review of the parts, via e.g. the blogsphere, and then pull them back into a whole

<DanC_> (yeah... I heard "sections", not "documents")

TVR: Yes, so we do the divide up at this meeting to get this moving

DA: Yes, emphasize casting the review net very widely

TVR: Focus on both desktop and mobile

<jar> re "requires trust", you don't need to trust something that's not authorized to do anything harmful. (e.g. script-free html, or a script running with only benign rights). sometimes you'll need trust, sometimes not.

JK: What about Web Sockets/XMPP -- how do those fit in?

TVR: Web Sockets is a back-channel between the browser and the server, could use HTTP, so this is definitely in scope

TVR: XMPP is also, particularly because of Jabber

NM: Wrt Flash, it's a big system, including it is like trying to do C programming

NM: So include it, but only when it's involved with the Web, not just any computation

HST: Same for Javascript -- can use it to write a Hidden Markov Model simulator. . .

TVR: Yes, the focus is on the web interaction aspect, not what happens inside the black box, e.g. internal memory model
... Javascript array/JSON hash/Flash blob just doesn't matter

JK: I didn't include browser plugins, not only because of Turing complete, but also because you get beyond the idea of sandboxing/managed code
... So e.g. Flash can get access to any aspect of the host, because it has direct OS access
... Whereas the sandboxes have a much more restricted model

NM: But Firefox could change its mind on this next week, and give more access too
... look at the geoloc api for example

<jar> we trust the flash platform *not* to give its rights to the script

AM: Could we use JK's taxonomy to start the division?
... Add use cases, problems and proceed from there

HST: Flash allows write to local disk?

DC: Google suggests it does

<DanC_> Reading and Writing Local Files in Flash Player 10

NM: Mike and camera are (subject to user control) available to Flash
... as well as a local store
... Looking at the ToC again
... given that we're talking about dividing things up
... [projects

<noah> http://www.w3.org/2001/tag/2009/09/webAppsTOC-20090921

]

TVR: Taxonomies are useful, writing down uses cases isn't necessary, as they are all around
... Architectural descriptions are the focus

DC: We have five topics, history is not so relevant
... we need names

NM: Section titles are ...
... back to older version
... includes Security, Client-side ???

TVR: Candidate section titles could now come from my earlier outline plus a few bits

<raman> What is missing in JAR's outline:

<raman> Construction of in-memory model from bits on the wire, and creating an interactive application from such a memory model using eventing and event handlers

<raman> Might fit into his final section, but personally I'd put it in a different section and earlier

<raman> it would also better motivate the sections on identification and naming and authorization etc

<raman> 1. Web Applications --- from server-side widgets to client-side widgets and beyond

<jar> my sections were mostly whimsical. i thought 3 minutes on how to put the list of topics into some order, and it's what I came up with. I'm sure there's a better way to organize the document

<raman> 2. Wire-level protocols for using Web technologies, HTTP, HTTPS, and addressing web resources

<raman> 3. Building in-memory representations that are live --- i.e. building a live DOM from the wire

<raman> 4. Eventing, Handlers, and retrieving more web resources in response to interaction AKA the web programming model

<raman> 5. Authorization, Authentication, Resource identification and Trust

<raman> 6. Deployment scenarios --desktop to mobile and beyond --- e.g. a java app on mobile fetches a web resource --- and forks a web view to further user interaction

NM: [building an HTML version, merging with JAR's old ToC]

TVR: I'll take that and try to cleanup
... Logical sequence is as follows: bits off the wire; building a live dom; back to the Web; authorization;

<noah> Here's the URI for the live copy of the outline that we're editing: http://www.w3.org/2001/tag/2010/03/webappsoutline.html

JK: The diagrams fit into item (2) in the outline: From Server-side to client-side. . .
... So I will try to integrate those into that section

AM: Maybe include "[some webapp] is an example of this structure" in each case

JK: TVR asked if I would take on the security section
... and I could do that

TVR: Because work you've done already fits in there

<DanC_> ACTION: John work on diagrams in "From Server-side to client-side" section of webapps material [recorded in http://www.w3.org/2001/tag/2010/03/26-minutes.html#action02]

<trackbot> Created ACTION-416 - Work on diagrams in "From Server-side to client-side" section of webapps material [on John Kemp - due 2010-04-02].

JK: Would have to do some writing to do that

<scribe> ACTION: John to frame section 7, security [recorded in http://www.w3.org/2001/tag/2010/03/26-minutes.html#action03]

<trackbot> Created ACTION-417 - Frame section 7, security [on John Kemp - due 2010-04-02].

NM: Good start
... Hoping someone will pick up client-side state this afternoon

DA: I want to contribute, not sure where. . .section 2, setting the scene
... Widget packaging

<DanC_> (DKA, I second the idea of you working on packaging in section 8 deployment)

NM: Mobile distinct?

DA: At least implicitly needs to be evident that 'no', everything applies to both mobile and fixed deployment

NM: Team up with JK on section 2?

DC: Widgets in section 8: deployment would suit your widget packaging thing, DA

TVR: I'll take the section 4 and 6, building DOM and eventing

AM: I'll contribute on section 5, app state

NM: There are two aspects of this, long-term persistent and short-term
... AM and TVR have looked at these, respectively

DA: What about APIs, for example geo and DAP ?

<DanC_> (interaction model section? where is that?)

NM: JR had a section for that at one point
... Re-title section 6 to include APIs

HST: JAR for section 3

<johnk> action-417 due may 1st

<trackbot> ACTION-417 Frame section 7, security due date now may 1st

JAR: What's section 3 about?

TVR: When you have a webapp made up out of HTML, CSS, Jscript, all are fetched by HTTP, then we go around again via AJAX

JAR: Not something I know much about

TVR: I bet Dan C. could help

NM: We could try to find someone for each section, and if people are uncomfortable, we could offer help
... or we can just leave some empty

JAR: Not for me unless I'm a picked victim

DC: Time frame should be sooner than London

TVR: That's what I meant by blogging -- I will blog on my own
... others can do so, then bring text in chunks to www-tag

NM: For process reasons, I prefer to see TAG discussion topics to be linked from a permanent location
... So please work in W3C space as soon as possible

TVR: Getting TAG agreement to publish is slow

NM: Not talking about approved, just mail to www-tag as soon as you can
... This isn't consensus, so just make clear that that's the case

TBL: Or use the TAG blog -- doesn't require TAG consensus

JK: I am not sure a highly interactive workflow works for me, I will work more in bursts

<Zakim> DanC_, you wanted to offer to archive stuff that's blogged elsewhere in the name of speed/audience/etc.

DC: I will archive in W3C space if necessary

NM: My concern was about IP policy -- if DanC archives, that has an effect in this regard

Meeting with W3C CEO Jeff Jaffe

NM: Welcome to Jeff

JJ: I'm trying to find out how things work around here, and understanding the TAG is on the list
... When I joined, TBL described a lot of goals for me
... The crispest headline was to create a vision for the organization of the W3C going forward
... I'm not ready for that conversation with the AC yet, but the AB looked like a good starting place
... So I presented to them, can we find six big things we need to address
... The size is important -- too big gets us nowhere, too small and we can't tackle enough
... So stimulate convergence with a list as a starting point
... I asked for 3 hours, we had 8, we converged well
... Added, subtracted, ended up with 5 headline items
... Roughly as follows:
... 1) Continuing to strengthen our core mission
... [I'll expand that later]
... 2) Make W3C the place that people want to bring new standards to
... [that came from the reaching out to developer topic]

JJ: These do all of course overlap a bit, depend on each other, not really prioritizable
... 3) Establish a sustainable business model
... We are surviving now courtesy of ISOC, but the situation is not stable in the long term -- we can't keep issuing unfunded mandates
... There are challenges behind (2), and addressing some of those will need more funds
... 4) Drive a truly global and accessible Web
... This includes BRIC, as well as Web Foundation and increasing access elsewhere
... Last was hardest to define and most controversial
... 5) Increase our value to users

JJ: The word 'user' has a lot of different meaning, covers everything from developers to. . .non ICT-companies,
... verticals, etc. -- Lots outside our core constituencies

<timbl> "users": "people who are not developers"

<DanC_> "In economics, BRIC (typically rendered as "the BRICs" or "the BRIC countries") is a grouping acronym that refers to the related economies of Brazil, Russia, India, and China." -- http://en.wikipedia.org/wiki/BRIC

JJ: So there's a sense that we need to expand our reach, in ways we can't yet fully agree on

DA: What about 'stakeholder'

TBL: Stakeholders are people invested in things, which doesn't cover classes of users

TVR: Who would miss us, would they really miss us, can we increase the set who do miss us

<timbl> "BRICK - and Korea" -- raman

JJ: I want to get this out to the AC, with some backup, early next week
... then a lightweight effort over the next three weeks with Team and interested AC to make this more precise in terms of what we mean, to report to the AB at the end of April
... Then the heavy lifting starts: How do we make them happen?
... Supposing we have consensus that the 5 are right as elaborated
... Then we work for some months on developing answers
... AB says that process involves 7 things -- the 5 above, plus how do we market W3C
... plus, I think separate from (1) above, is the question of what the scope of the W3C is.
... We are not the only place that does Web standards -- that's OK, but I don't see where we have intellectual clarity on which Web standards belong here
... So that we know when we should feel really bad wrt some work getting done elsewhere, and when not
... And even then sometimes it's OK if work starts elsewhere, as long as it comes here in the end
... So clarifying this feeds goal (1), but I think it's large, complex and separable from (1)

NM: Also connects with the business model -- historically what we work on is significantly determined by what Members will pay for and send engineers to work on. . .

JJ: From the outside that looks like it's harmful to the Web: when important work is done elsewhere it hurts
... architectural integrity
... Should we take a stand against that, particularly when a Member company takes work elsewhere

DC: It makes them more likely to move when we do, because they don't like what we say about Arch. Integrity

AM: I've been in discussions at Oracle along the lines of "Which body do we take this work to for standarization?"
... My colleagues see different pluses and minuses for the different bodies
... I'll send JJ something one of them wrote

DC: The TAG history comes in 3 parts -- before the TAG, before publication of WebArch, after publication of WebArch
... Before the TAG, TBL would say to WG chairs "don't do that, it breaks WebArch", and eventually they pushed back and said "What is this WebArch of which you speak?"
... TAG was chartered to try to answer this question
... Tim Bray and Ian Jacobs did a lot of work, Ian catalysed a lot
... We sort of knew what the architecture was we were writing
... We took the document through the Process, and published in 2004, felt pretty good
... Well-received
... Since then we've done some stuff. . ..

NM: The other publications we do, starting in overlap with WebArch, are Findings
... Not usually in the Process, vary in quality and impact
... Authoritative Metadata is a good example
... either complementing or fleshing out aspects of WebArch

JJ: Do we go back to the WebArch and edit it to point to them?

NM: No, Process issues, we have a list

TBL: TAG work started out with Findings, we pulled some of those together into WebArch, since then we have not pulled findings together
... Volume 2 has never happened -- no agreement on pulling together new stuff, or expanding V1 to cover e.g. Semantic Web and WebApps

JJ: I was suggesting you could just flag in v1 areas where later Findings are relevant

NM: Possibly
... Picking up a few years ago we've been unsure about whether our working mode was having much impact
... We agreed three major goals: Working with HTML WG to make HTML5 the best it can be; Figuring out how to bring WebApps into Web Architecture; Getting a better picture of Metadata in its many forms
... Focussing on the first has led us to fewer publications, but a lot of interaction and back-and-forth on issues

JJ: Bringing this back to what is the scope of W3C, which we really need a perspective on
... whether we convince the world or not
... The TAG tends to operate one level than that -- more detailed architecture for one particular thing
... rather than the arch as a whole
... Everyone works topically, the AC, the AB: conversations about HTML5, accessibility, etc., but I don't see anyone looking at the entire space

NM: There are the three pillars set out in WebArch

JJ: I don't see where a lot of things fit with that -- Web Services? Web3D?

TVR: This notion of the landscape of standards, and how things fit together, hasn't been a focus

NM: We have worked here in some cases, such as saying HTML5 spec. overlaps with IRI spec.

TBL: We have talked about scope, in the early days. Connects with the question of how we find new work.
... Not just what is our scope, but how our scope expands
... Research is important in feeding into this, for example SemWeb for Distributed Social Networks -- OAuth is something we missed
... We should bring that in

JJ: Connection with research. I'm very positive about this, but I got a lot of pushback on this, including from the AB.
... Position was a bit that our Members have 1000s of research staff, what could we hope to do

JJ: Reformulating to put "Where standards come" first leaves a place for this -- not only push from the Members, but pull from the Team: if the Team is seen to be technically savvy because of research credibility, that helps

<Zakim> DanC_2, you wanted to talk about writing resources

DC: We have fallen below a critical mass of writing resources
... For example, the deep linking area was something we felt we should be involved, but couldn't marshal the resources
... I took an action to try to get resources for this, but haven't made progress

<Zakim> timbl, you wanted to talk about scope, research, social web etc

NM: The wrong writer would be worse than nobody

JJ: I have heard a lot of requests already, but we are resource-constrained right now, very difficult to prioritize w/o getting those five goals agreed
... If you can't fit writing resources into that story, then now is the time you need to push hard

DC: I wasn't special - pleading

JJ: I understood, just emphasizing that we have to have some means of prioritizing

<Zakim> noah, you wanted to talk about research

NM: One of the interesting things is how our membership is chosen -- writing skills come or they don't, as does technical expertise
... the TAG doesn't always have the people to cover some of the things you've mentioned
... For example, we just don't have the kind of expertise on Security that we do on HTTP
... Regarding research, there's a tension between WGs that invent new things,
... and WGs that ratify things that are nearly baked

NM: The former is a strain when anybody who turns up from the Membership gets to participate
... The same thing may happen in the research area

DA: I'm in favor of the research idea -- I like the W3C as sitting between industry and academia
... it's an important aspect of W3C for my company

JJ: I'm looking for passionate support or critique from the AC on these points, to help get involved with clarifying this

DA: The WebApps Arch document which we got closer to scoping today will address some of these issues

TVR: Research is a good thing, on the top-level goal, reframe as "W3C is the standards body which people bring new work to"
... On the marketing point, it is a problem -- I see the weekly email newsletter as low in impact

TVR: When there are new RECs, the press release avenue for publicity is also not doing as much as we need

<Zakim> timbl, you wanted to say that people do read the newsletter

TBL: I've had anecdotal input in the other direction wrt the newsletter

DA: I agree

<Zakim> johnk, you wanted to ask what we can do for "ordinary web developers"

JK: Amplifying what TVR said, in my company trying to involve ordinary employees in paying attention to WebArch, that as just one person it's very hard to make that connection on a broad front -- we're a big company

NM: The artifacts are useful, but people aren't finding them

JJ: That also feeds into my point (1): not just clarifying our scope, but improving the uptake of the specs we've already published

NM: Maybe we need new resources to focus on publicize the importance of our work

JJ: Connect this back to our goal being to promulgate our standards, and that will work

NM: The pushes back onto the TAG to clarify our own success criteria
... Adjourned until 1315

JJ: I would like to hear from the TAG as to whether the scoping exercise is useful for W3C, and assuming it is, what role the TAG should play in that exercise: Doing, leading, participating, observing, . . .

<scribe> ACTION: Noah to initiate discussion of what the TAG thinks of JJ's proposed scoping work, and whether and if so how the TAG will participate [recorded in http://www.w3.org/2001/tag/2010/03/26-minutes.html#action04]

<trackbot> Created ACTION-418 - Initiate discussion of what the TAG thinks of JJ's proposed scoping work, and whether and if so how the TAG will participate [on Noah Mendelsohn - due 2010-04-02].

JJ: First relevant deadline is 26 April AB meeting, input before then on definition in particular would be good

--------------------------------

ACTION-407

HT: HTML media type section 12.1

<ht> http://dev.w3.org/html5/spec/iana.html#text-html

<DanC_> ACTION: Henry edit minutes for ftf day 3 (Friday 26 March) [recorded in http://www.w3.org/2001/tag/2010/03/26-minutes.html#action05]

<trackbot> Created ACTION-419 - Edit minutes for ftf day 3 (Friday 26 March) [on Henry S. Thompson - due 2010-04-02].

HT: Dan says "existing content varies considerably"
... I'd like to expand this to give more of the history
... largely copied a section of existing RFC 2854

and added new sections on interop considerations

HT: no current language in the HTML specification regarding what constitutes a "conforming document"

<DanC_> (noah, if you could find that bug, I'd appreciate it; I tried to find my years-old comment about definition of conforming document, but couldn't find it)

<timbl> a/asserts/wejhfkjqwehfk/

HT: "labeling a document with the text/html type asserts that the document is a member of the HTML family"
... conformance for user agents is a defined term in the HTML specification

<DanC_> "labeling an orange 'made in USA' asserts that it was made in USA". seems OK to me.

TBL: I prefer Dan's original text regarding "processing by user agents"

HT: "licenses the interpretation of that document as a member of the HTML family..."?

TBL: saying "this document is the relevant specification" seems redundant

HT: standard text in media type registrations

NM: how are you dealing with the older spec. issue?

TVR: what happens when a new browser sees an HTML3 document?

HT: language covers that and says "interpret it as HTML5"

NM: same language says "old browsers are not buggy to interpret it as HTML3"

TBL: essentially say that "this specification is designed to cover both interpretations"

TVR: HTML5 says what a browser should do

<DanC_> (I don't understand raman's point.)

<Zakim> timbl, you wanted to complain about the asserts language

TVR: should be careful to say that not all UAs should interpret HTML3 according to HTML5 specification

<ht> timbl prefers licenses to asserts

NM: in your IOP considerations section, I think you meant "conforming to the HTML spec" but there's a sense it felt like "conforming to the media type spec"
... mention the bug report I put about the lack of a link on conforming document

<noah> The HTML 5 bug regarding the term "conforming document" is: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9178

<Zakim> DanC_, you wanted to invite the tag to try a modern collaborative tool http://etherpad.com/a5calzHGRK

DC: responded in email that this text is "close enough"

<timbl> Labeling a document with the text/html media type licenses its interpretation according to this specification. This specification is designed so that the inter-operation of a document written to an earlier definition of this media type is equivalent to the inter-operation of that document under those earlier specifications.

HT: will return to ACTION-407 later today

Mobile Web Considerations

DKA: would be happy to add more technical considerations; didn't have time to do that yet

DKA: "mobile is not a category we should be thinking of separately from the rest of the Web"

<DanC_> "To purchase a copy, please click here." -- http://www.morganstanley.com/institutional/techresearch/mobile_internet_report122009.html

DKA: growth of mobile Internet usage is outpacing desktop usage (and related statistics)

<DanC_> Mobile Slides for TAG

DKA: mobile device constraints: small screen, CPU weakness, constrained input devices, battery usage, not easily addressable, cost, lack of "field-upgradability"

AM: does that mean phones don't have stable URLs?

DKA: Correct

TVR: I can decide in Bluetooth whether my device is visible or not, why can't I decide for the presence of my mobile on the network?

DKA: I don't think anyone is thinking about this right now
... device capabilities: some constraints are also capabilities (small screen, low power)
... also, "with you at all times", presence of sensors (local, personalized context such as GPS, camera) -> uniquely personal
... e.g. Google Goggles - (augmented reality application)
... privacy is important (phone number, location) - DAP APIs will open up more information subject to privacy policy

DKA: mobile networks are complex
... IP is a layer on top of a complex network system (already)

<DanC_> "Access point name (APN) identifies an IP packet data network (PDN), that a mobile data user wants to communicate with. In addition to identifying a PDN, an APN may also be used to define the type of service, (e.g. connection to wireless application protocol (WAP) server, multimedia messaging service (MMS)), that is provided by the PDN. APN is used in 3GPP data access networks, e.g. general packet radio service (GPRS), evolved packet core (EPC)." -- http://en.wikipedia.org/wiki/Access_Point_Name

DKA: often there is transcoding software - for down-sampling JPEG for example
... latency and bandwidth considerations
... network is designed for ubiquity though
... ... and simultaneous connections
... ...unlike WiFi
... brief history of mobile markup

<DanC_> (on how to do wifi with 500 people in the room, people are raving about the network at pycon 2010 in atlanta, timbl)

DKA: phone.com / openwave HDML
... WAP/WML
... XHTML basic, and then HTML5
... XHTML basic is a cut-down version of XHTML, which doesn't have draconian error handling

<trackbot> Created ACTION-420 - What is different about XHTML basic 1.1 (in particular re: namespaces) [on Daniel Appelquist - due 2010-04-02].

NM: we've heard that "namespaces are hard, strict parsing is hard" but mobile devices are doing these kind of things

TVR: suspect that mobile industry would prefer that mobiles didn't have to handle all the bad content out there
... messy documents will not be popular on mobile

TBL: does everything get compressed anyway?

DKA: will get to EXI in a bit
... MWBP focuses on non-smart phones

NM: are there predictions for the phase-out of "feature phones"?

DKA: manufactures are still producing feature phones
... got feedback that there was a lot of usage of feature phones in developing markets
... MWBP focuses on wide accessibility
... transcoding proxies exist and MWBP now covers them
... most phones sold worldwide are still feature phones (i.e. XHTML basic)
... but some websites now only support smart phones
... widgets...
... see Apache Wookie

http://getwookie.org

DKA: how does HTML5 app cache relate to widgets?
... DAP "great power, great responsibility"
... web developer gets access deep into the phone (contact book, location, and so on)
... EXI provides a dramatic increase in efficiency but it's not widely deployed

TBL: you have to feed it well-formed XML

DKA: no, you can feed it non well-formed markup

NM: you can agree on the tag dictionary and that's when you get the dramatic speedup

DKA: even without a shared dictionary, you get a big speedup
... introduced EXI to OMTP

TVR: does EXI have a story for CSS/JS?

DKA: I think it works, yes

TBL: EXI works on infoset

HT: yes, so well-formed isn't an issue

NM: I would define a mapping from DOM to EXI

TBL: does EXI push you to XML serialization or not?

DKA: I think it allows tag soup

HT: (reads the spec. which doesn't seem to require well-formedness)

NM: if we want to help the world understand how fast EXI is, we need to tell the full story

DKA: EXI would be best at the network edge
... i.e. EXI implemented in a proxy

TBL: why wouldn't origin server just produce EXI?

DKA: was thinking about radio networks
... on networks - new network technologies coming "4G": LTE and Wimax
... idea of the "mobile web" has changed from viewing of static documents to "content production" (i.e. taking and sharing picture) - more interactive environment
... "greening of the Web" coming from mobile
... problem with apps consuming battery power
... it has been said that the move to web apps would make this problem worse
... how to support apps running, without wasting power?

NM: are people aware of 4G rollout?
... roughly, this is the early rollout year for 4G, and will ramp up over the next couple of years

DKA: yes, it's rolling out first for dongles, not phones

NM: most mobile carriers are doing LTE, but cable companies for example, are doing Wimax instead
... for people who weren't bound to mobile...

TBL: why dongles, not phones?

DKA: because they think people want ubiquitous connectivity from their laptops

TBL: are these entirely different technologies (Wimax and LTE)?

DKA: not really...

NM: Wimax is licensed spectrum, Wifi not licensed
... Wimax politically comes out of Wifi, but it is competing technically with LTE
... most people think LTE will win in the USA

DKA: all have the same issues with urban, rural deployments

NM: at a pretty low-level they are both deployed as IP networks
... and my impression was that you'd be doing voice over IP if you made a voice call

HT: just on EXI: looking at the spec. EXI is about processing infoset
... aside from corner cases around namespaces
... there are only few infosets that couldn't create well-formed XML

TBL: issue was about whether you would use EXI with WF XML or tag soup

NM: natural way would be to conceive a DOM, and map it to an infoset

HT: ill-formed XML can't occur with EXI

NM: so then convert the HTML to DOM, using HTML specification

<DKA> http://www.w3.org/TR/exi-primer/

TBL: would like the TAG to get a report on EXI usage at a future meeting

<trackbot> Created ACTION-421 - Frame the discussion of EXI deployment at a future meeting [on Henry S. Thompson - due 2010-04-02].

DKA: browser use-case is not the only interesting one for EXI - mobile infrastructure is interesting too

JK: for example, streaming TV metadata was one important driver for EXI

text/html registration

DKA: querying Tim's use of the word "license"

TBL: as in "permit"

DKA: "license" engages lawyers

<noah> I am happy with that use of "license", but I have been criticized in the TAG, perhaps by TBL, for doing the same in drafts of the Self-Describing Web document.

TBL: if I send you a message with metadata how to interpret the message
... ...you can hold me to that interpretation

<ht> where for metadata, read, inter alia, media type

TBL: you can blame me only when you interpret based on the media type
... if you sniff, all bets are off

<ht> web-architecture-normative sense of 'license'

DKA: you're talking about a moral sense of "license"?

TBL: no, architectural sense
... what is the reader allowed to conclude from a message (or the headers of the message)?

<noah> http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

TBL: fundamental point of webarch is the use of the media type

NM: what can you conclude based on the applicable specifications?

TBL: if you can think of a better word than "license"...?

JK: "permit" (as per Tim's earlier comment)?

HT: too weak IMO
... interop statement in my text is the first place where we say that HTML3.x will get processed reasonably effectively by processors which conform to this spec
... there is bug in HTML5 where it comes close to equating user agent with web browser, but there are several other conformance classes

<ht> http://dev.w3.org/html5/spec/infrastructure.html#conformance-requirements

HT: if there are specific flaws in the HTML conformance requirements, we should say something - at least it deserves review

<timbl> Labeling a document with the text/html media type licenses its interpretation according to this specification. This specification is designed so that the inter-operation of a document written to an earlier definition of this media type is equivalent to the interpretation of that document under those earlier specifications.

HT: that's not descriptive
... the original concern was the apparent "blacklisting" of any server that serves HTML4 as text/html

NM: my concern is that we should explicitly reference the old versions
... some things from old specs. are not legal in HTML
... so, an old UA would no longer be legal either if it processes things in old specs. not in HTML5
... this media type may be used to serve content with the following document types

HT: that goes beyond what RFC 2854 did

NM: did any of the older specs. eliminate things from previously older specs?

HT: yes 4 ruled out things in 3, etc.

TBL: what is the design goal?

HT: will get back to that

TVR: this is an update to the media type, yes?
... why don't we expand the set of documents covered by the media type to now include HTML 5 and point to RFC 2854.?

TBL: point is that it shouldn't matter - if you find HTML2 engine or HTML5 engine, both should work

TVR: not all implementers buy into the HTML5 strategy

TBL: yes, an HTML2 processor should still be legal

TVR: simply add HTML5 spec. to the existing registration and point to HTML5 specification

<Zakim> noah, you wanted to ask about old specs and to

TVR: Just use the HTML5 doctype if you want HTML2 to be processed according to the HTML5 spec

NM: old stuff will be reasonably interpreted according to the new spec.
... but there is an old small %tage of content where the new spec. will say "this is not HTML"
... I want the media type to say "yes it is"

<Zakim> ht, you wanted to quibble about intent

HT: authors of HTML5 spec. don't mean "render HTML4 docs according to the HTML4 spec"
... their goal is to render it according to how how current browsers do it
... existing registration makes no guarantee about what will be done with the content

NM: it does say what a <p> says/means according to HTML4
... it also says "this is legal syntax"
... my question is about "things that would become illegal under the new specification"
... if I make the only normative spec. be HTML5, then some old documents will become non-conforming

<Zakim> timbl, you wanted to say, Noah, that there is nothing about validity of documents

TBL: mime type has nothing to do with conformance
... only about interpretation

NM: what I'm saying is that if a document is served which now creates an "error" when yesterday it was valid

HT: it's perfectly OK to say in a media-type registration that "here is a new header to go with that"
... it is appropriate to ask whether this message conforms to the media-type registration

<timbl> timbl: Mime type registrations do not define conformance for a mime type. The specs they point to may define conformance (of various kinds) for documents of various kinds.

HT: media-type has nothing to say about the document conformance

NM: so where is it an error?

HT: in the relevant applicable specification

<ht> It says "this is not a JPEG" per this specification

NM: so, are we happy that this will happen for old HTML documents that do not conform to HTML5?

<ht> It does not say "serving this as image/jpg was a violation of [some RFC]"

<ht> So, answer to your question, "yes, I'm happy"

<ht> We say "this message body is not a conforming HTML document per HTML5", not "this message is not correctly labelled text/html"

<timbl> ---------------------------------------------------------

TVR: every time this comes up some implementers complain as they don't wish to process according to HTML5

ACTION-407?

<trackbot> ACTION-407 -- Henry S. Thompson to propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or incorporate the HTML history, similarly to the way 2854 does -- due 2010-03-25 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/407

<ht> action-407 due 13 Apr

<trackbot> ACTION-407 Propose an update to DanC's prose from http://lists.w3.org/Archives/Public/public-html/2010Feb/0878.html to explicitly reference or incorporate the HTML history, similarly to the way 2854 does due date now 13 Apr

<ht> action-407: HST to redraft on basis of f2f discussion 2010-03-26

F2F arrangements

DKA: meeting room is confirmed

<noah> http://lists.w3.org/Archives/Public/www-tag/2010Mar/0018.html

Client-side identification

NM: we (Raman) wrote a draft
... I took ACTION-353 to write notes about client-side identification in AJAX
... related to Raman's draft
... let me remind you about "metadatainURI"
... URI template-like usage is good
... we talked also about HTML forms
... HTML forms programs the browser to tell you about some fields
... if the form came from the same authority as the URI assignment authority, then it's definitely OK
... but if it comes from some other authority then it might be OK
... then we have the Google Maps case...
... there's a URI for the map, centered at a lat/long
... Google knows it has created URIS in this way
... app sends me some AJAX
... client constructs a URI probably with lat/long
... can use back/forward button
... but can also email that URI to someone else
... next time Google sees it, it will be at the server
... (it being the URI)

NM: I think this is similar to the forms case
... would like to suggest we add a story to Raman's finding
... you have encoded information about the URI Policy
... URIs going to conceptually different resources
... there's an interesting story to tell there - why is that OK, why trustworthy?

TVR: why is there something new here?

NM: trying to say that this is a pattern we encourage
... and connect the AJAX case to the HTML forms case
... and why Google Maps e.g. is better than those apps which don't assign URIs in this way

TVR: also the symmetric client-side case
... when you hand URL to the browser, # doesn't go to the server
... part after the # has a JSON dictionary
... server sends back Javascript which examines the location bar to get the current state of the JSON dict
... also analogous to the forms case

NM: I hear you say that you are adding to what I have said
... would like to tie this back to the applicable specs.
... is this use of # acceptable?

TVR: I believe the # in HTML says "move to the element whose id is linked after the #"

NM: would like to check for "squatting"
... should lay out this story, how it builds on the applicable specs. and how it stretches those specs.

TVR: I added some text about an interesting JS hack
... to my draft finding

NM: are you willing to take an action?

<trackbot> Created ACTION-422 - Examine the current text of his client state finding and update appropriately with Noah's email from ACTION-353 [on T.V. Raman - due 2010-04-02].

<noah> Noah's ACTION-353 email was http://lists.w3.org/Archives/Public/www-tag/2010Mar/0018.html

ACTION-422: linked to ACTION-353

<trackbot> ACTION-422 Examine the current text of his client state finding and update appropriately with Noah's email from ACTION-353 notes added

ADJOURN

- DRAFT -

TAG f2f

26 Mar 2010

Attendees

Contents