See also: IRC log
<trackbot> Date: 17 May 2012
<scribe> scribe: Masinter
<scribe> ScribeNick: masinter
<noah> No regrets
<noah> RESOLUTION: Minutes of 3 May are approved http://www.w3.org/2001/tag/2012/05/03-minutes
<noah> Jonathan can scribe next week
<noah> NM: Who might work with us on DANE?
<noah> LM: Hannes Tschofenig is interested in working with the TAG
<noah> I'm not sure that PERL matches well on ???? special characters
<trackbot> ACTION-697 -- Larry Masinter to prepare overview of DANE for TAG consideration -- due 2012-05-16 -- PENDINGREVIEW
Larry: bump date
<trackbot> ACTION-697 -- Larry Masinter to prepare for discussion of CA infrastructure weakness (e.g. DANE) -- due 2012-05-29 -- OPEN
noah: everyone knows f2f is in boston, logistics should be familiar to all (perhaps except Robin)
<noah> The +1/-1 is for who will be at F2F
<noah> We're not sure about Robin
<noah> close ACTION-703
<trackbot> ACTION-703 Put health warning in "Booth Script" for formatting minutes closed
<trackbot> ACTION-690 -- Jeni Tennison to sort next steps on Fragment Identifiers and Mime Types -- due 2012-05-05 -- PENDINGREVIEW
discussion of topic, content, logistics
Jeni: not much changed from the
content that was there before, building on the negotiations on
the media type registration document, and making the
recommendations more concrete
... Having now written a draft on this, the topics that make sense to cover are the structure syntax suffix registration, also for anyone writing fragment definitions ....
... we want to do this fairly rapidly, the timeline is based on having something we can review at F2F, going through drafting
ashok: If you want to recommend what people ought to write or how they are to write fragment id specifications. But most of this is fixing bugs in things, that doesn't look like recommendation to me.
<Zakim> ht, you wanted to mention http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt
ht: the IETF is gearing up to standardize the "+" suffix practice such as used in +xml
<JeniT> suggest to cover: what people should write in media type registrations, structured syntax suffix registrations, guidelines for defining fragment structures (eg XPointer / media fragment URIs), and guidelines for publishers and authors that refer to URIs with fragment identifiers
ht: it includes specifically a
(slightly broken) reference to 3023
... hoping Chris Lily will respond
... I would like people to review it, and especially section 8
... it seems to amend 3023 on the fly
discussion of comments
<noah> ACTION: Henry to keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis - Due: 2012-??=?? [recorded in http://www.w3.org/2012/05/17-tagmem-irc]
<trackbot> Created ACTION-706 - Keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis - Due: 2012-??=?? [on Henry Thompson - due 2012-05-24].
<noah> arghh...meant to put a dot in front of that
<noah> close ACTION-706
<trackbot> ACTION-706 Keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis - Due: 2012-??=?? closed
<noah> . ACTION: Henry to keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis - Due: 2012-??=??
<noah> LM: I'm feeling we should act sooner
discussion of how to send comments to the IETF and what to say on the document and how we would review it
Henry: I will do that (raise the issue with Tony Hansen)
<noah> ACTION: Henry to keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis - Due 2012-05-05 [recorded in http://www.w3.org/2012/05/17-tagmem-irc]
<trackbot> Created ACTION-707 - keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis [on Henry Thompson - due 2012-05-05].
<noah> ACTION-707 Due 2012-06-05
<trackbot> ACTION-707 keep an eye on http://www.ietf.org/id/draft-ietf-appsawg-media-type-suffix-regs-00.txt and relation to RFC 3023bis due date now 2012-06-05
http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs is a better document
<noah> ACTION: Henry to check with Chris Lilley on likely near term progress of RFC 3023bis [recorded in http://www.w3.org/2012/05/17-tagmem-irc]
<trackbot> Created ACTION-708 - Check with Chris Lilley on likely near term progress of RFC 3023bis [on Henry Thompson - due 2012-05-24].
<Zakim> noah, you wanted to ask about the split between success criteria and deliverables, and also what should be in IETF documents vs. what should be in our new Recommendation
noah: concern about the product page, so that the dependency between IETF and Rec? What is left that is extra?
Jeni: if you look at the media type registration document, it contains very little guidelines about fragment identifiers
<noah> From the 2nd success criteria: "The TAG will work with the IETF and the W3C to update the templates for MIME type registrations as necessary to promote consistent and accurate documentation of fragment id semantics"
<noah> NM: If that's done, what's left for the Recommendation?
the template should point to our rec once we have one
jeni: it includes in the template an area where people can talk about fragment identifiers in depth
<noah> JT: It's done, but it only gives us an area in which to put.
noah: if you could update the
product page to clarify, that would be helpful
... say taht the template has been updated, but the template doesn't ahve guideance
<noah> NM: I have some preference for updating the product page to make clear what's not in the IETF templates, and what therefore should in our Recommendation
<noah> LM: The IETF stuff should, ideally, point to the Recommendation saying "look over there at the helpful guidance the W3C has given you for doing this well"
<noah> LM: Might or might not be W3C, but yes. And that's why we need Recommendation, so there is formal community consensus.
<Zakim> masinter, you wanted to talk about why 'rec'
discussion of whether this is a top priority
<noah> NM: So, are we all agreed that Jeni's plan in http://www.w3.org/2001/tag/products/fragids-2012-05-04 is what we want to do, and as a top priority.
<noah> Agreed with no objections.
<noah> JT: Larry's reviewing a draft, will soon go the TAG for review, hoping for lots of time at F2F.
<noah> NM: Absolutely, it's a top priority.
<noah> LM: It looks close to me.
lm: Ned already said he likes it.
noah: I would rather be early
than late in the schedule
... question on tag members listed .. everyone still ant to be listed?
noah: for F2F, most important
thing is things that we should have written
... what do we need to know about range-14 at F2F?
jar: hopefully we can wrap it up
without a lot of discussion
... Jeni, Henry and I are working on getting a statement we can agree on
... let's wait a week or two before deciding how much time to schedule
... I've been meaning to go over the product page. Given the lack of consensus in the community, i don't know if we can succeed.
... We might need to defer the issue to some other group
noah: there's a sense in which
we're punting on a goal. If we punt on a goal, i want to be
careful that we justify that.
... (more about prioritizing)
<noah> JAR: Give me a week or two before we settle the F2F plan on ISSUE-57
noah: next topic is publishing and linking. Should we have a session on it?
<noah> NM: Publishing and linking?
<noah> JT: Can you give me a couple of weeks to see if I manage some time?
jeni: let me see if i can get some time on it in the next couple of weeks
<noah> NM: Absolutely. Thank you for trying.
noah: (discussion of balance of
work and whether list of topics represents what we are
... I am inclined to schedule a session on TAG effectiveness, without much structure
<noah> LM: It could be organized, based on threads, such as finding vs. rec
<JeniT> +1 to having a session about general TAG effectiveness/goals
<jar> +1 too
<noah> NM: My inclination is to look at things somewhat top down, starting with our charter
<noah> LM: I'd be inclined to invite Jeff
nm: i think it would be useful to have a discussion among ourselves also
<Zakim> masinter, you wanted to propose meeting with W3C staff to talk about this
<noah> . ACTION: Noah to talk to Jeff & W3M about TAG futures
<noah> ACTION: Noah to talk to Jeff & W3M about TAG futures [recorded in http://www.w3.org/2012/05/17-tagmem-irc]
<trackbot> Created ACTION-709 - Talk to Jeff & W3M about TAG futures [on Noah Mendelsohn - due 2012-05-24].
nm: discussion of survey
<ht> Next AB meeting is on ... 11 June!
if AB is meeting 11 june, could we meet with them?
<ht> Which reminds me -- HST regrets for next week
discussion of XML / HTML task force and next steps
lm: +1 to xml/html topic
<noah> JAR: doing AWWSW wrapup
<noah> JAR: distinct from other ISSUE-57 work
<noah> JAR: Will try to get a draft done June 1, then we can decide F2F
<noah> AM: Storage session to decide what we're doing
nm: Ashok, can you put something together to review what the issues are?
ashok: the TAG might want to write a finding, "look, there are these mechanisms, here are the pros nd cons". That i think is relatively easy to write up.
<noah> NM: Specifically, can we do something that will identify the points of disagreement we've been thrashing on regarding what goals and success criteria should be, so we can try to settle them ahead of F2F?
<noah> AM: Difficult issues as to whether local items have URIs, synchronization, etc. Those are hard.
<Zakim> noah, you wanted to talk about architecture vs. detail
nm: I think the tag's job in all
this is to look after things that are architectural in scope,
and things that are part of web architecture
... some of the proposals look like they mix architectural issues with lower level things like IndexDB.
... what you say seems to sort things by 'hard' vs 'easy'
... Our question should be: if there is a design choice between storing things locally vs. remotely, how does that affect the design?
ashok: i'm trying to find how people handle this case, like offline email. I've had some difficulty finding out.
nm: should we cancel the effort on storage? I can't tell where you're going.
<jar> I thought that post was very informative
ashok: this is an interesting
post. Would a larger version of this be interesting? larger in
that we spoke about other local storage mechanisms
... or, should we take up a narrower issue, like the local/global URI question, and the problems of synchronization
<Zakim> masinter, you wanted to reply
<noah> LM: I see stuff like dropbox, iCloud, Adobe Creative/Cloud, blurring the line between local storage and Web storage. This should be part of Web architecture.
<noah> LM: I'm more interested in surveying what people are doing than making recommendations, because I don't think we know what to recommend.
the web is moving toward blurring the line between local storage and remote storage, and these new services will grow
<noah> I note that in the blog post, they do what I recommend, which is use local storage as a cache for URL-id's content.
<noah> See e.g. this line of code: document.body.innerHTML = localStorage.getItem( urlPath );
<noah> Note that it's indexing the local store with the urlPath
jar: it seems that what we call
'web architecture', the original design of the web; you could
imagine another path that included things like dropbox and
... if there were a place for architecture, and there's some analysis for people who are designing things
<noah> Is it really clear that Web arch is completely unprepared to integrate w/persistent store like Dropbox? I'm unconvinced.
jar: I don't know what kind of
thing one could say, though.
... where to put the boundary of such an analysis ?
nm: this is useful, but we're drifting scoping F2F sessions
jar: there's probably a lot to talk about if we cast a broader scope
<noah> LM: We have a list of TAG findings http://www.w3.org/2001/tag/findings, and we have approved findings and draft findings. I look at the charter and how we could lead the community.
<noah> LM: I think it would be worth the TAG time to go through the findings, to see whether the community is following them...cleaning them up to either get recs with community consensus, or "drop" them.
nm: i think it's more effective for people to do this offline individual review, and then come together to discuss
lm: suggest a survey
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/administration/Convene/ FAILED: s/administration/Convene/ Succeeded: s/????/Tschofenig/ Succeeded: s/mime and web/Fragment Identifiers and Mime Types/ Succeeded: s/sitll/still/ Succeeded: s/without/without much/ Succeeded: s/architeture/architecture/ Succeeded: s/NM/LM/ Found Scribe: Masinter Inferring ScribeNick: masinter Found ScribeNick: masinter Default Present: plinss, Masinter, JeniT, Ashok_Malhotra, Noah_Mendelsohn, Jonathan_Rees, ht Present: plinss Masinter JeniT Ashok_Malhotra Noah_Mendelsohn Jonathan_Rees ht Agenda: http://www.w3.org/2001/tag/2012/05/17-agenda WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 17 May 2012 People with action items: henry noah WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]