See also: IRC log
<johnk> scribenick: John
<johnk> ScribeNick: johnk
NM: (reviews agenda)
NM: dive into priorities discussion
NM: converted a spreadsheet so that all major items were done as single line
JAR: you should note the mismatch between what people want to work on and the listed priorities
NM: we didn't go over the open issues previously, so I have added the high priority items to this priorities list
NM: look at this list and identify 1/2/3/4 of these items that you are willing to work on
TBL: (questions process)
NM: if it doesn't look like a deliverable, then just skip it
<masinter> one more time
NM: look through list http://www.w3.org/2001/tag/coordination/groupPriority.csv and pick some items that you are interested in
<Ashok> 3, 13, 19
<raman> 4 9 10 17 21
16, 4 (perhaps not all/only in TAG), 5, 10/16 intersection, 3
I meant 10/13 intersection, not 10/16
LMM: should group/name differently
NM: we can revisit the naming
LMM: split out 22
NM: (roughly) yes
TBL, re-use 6,7,8 for sub-components of 22
I don't see any URIs here ;)
<ht> HST: 2, 4, 5 12, 17, 21, 24, 25
DanC: 6, 10, 20
AM, (adds 7 as a possibility)
TBL: 1/15,4/6, 8,12,14, 19
LMM: treats this list as things willing to talk about
... 1, 4, 5, 6, 9, 10, 11, 14, 16, 17 (then notes other things not on the list at this point) .... 27 (liason)
DanC: +1 to 27
TVR: changes 9 to 20 (web app state)
NM: given that I am chair will not put my name by them yet
(discussion of how to do clustering of issues)
LMM: offers to lead clustering
NM: let's try it for 10-15 minutes
... new version of the file at http://www.w3.org/2001/tag/coordination/groupPriority.csv
LMM: (moves to whiteboard discussion)
NM: as you fold these, let's remove the old ones
TBL: let's not remove anything yet, just group
4, 6, 17, 25
LMM: is it OK then to restrict error handling to HTML?
HT: let's not restrict anything yet
NM: let's remove 25 from cluster
... should 21 be in cluster?
first cluster now 4,6,17,21
TBL: 1,2,15,18,23 as cluster?
is 15 in this cluster?
HT: 15 seems orthogonal
NM: 23 should be separate
... move 'scheme/protocols' out of 1
<Stuart> Is there a difference between 18 and 19?
thinks Stuart might find it useful, but if not, I will stop?
<Stuart> Dan/John... don't worry about me... I doubt there is much that you can do to help me :-)
(stops recording whiteboard discussion for now)
HT: we didn't include conneg in this list
NM: (adds to list)
... (let's LMM continue to lead session beyond his granted 15 minutes)
TBL: combine 3, 15, 27?
... rules, education and liason are related
(discussion of 8 - semantic web)
HT: not losing track of URI-related resources and their relation to things "off the Web"
... linked data synchronization / update
... security is a cluster
LMM: I think we can't look at one without relating to the other
<Stuart> I wonder to what extent TAG attention to security is informedBy, duplicates, or contributes distinctly from the activities of exting security focussed WGs at W3C
first task is probably to investigate exactly that - whether there actually *is* work to be done by TAG here
TVR: suggests making a matrix to prioritize according to some set of criteria
(such as member-indicated interest)
6,Avoid doing things we can't complete
7,Put as low priority things that have only short term value. High priority to things that produce documents that have long term value.
8,"We should emphasize activities that produce artifacts"" of long term value (findings, etc.)"
(pasting old lines from Noah's file)
TVR: we should try to connect WGs when working on a particular question
LMM: we should try to estimate the audience for our work on each issue
TBL: TAG provides the glue between WGs
... if something falls between the cracks of WGs, TAG should do it
LMM: do the things that *only* the TAG could do
NM: what we need to get to from this is more focussed priorities
LMM: we have put a lot of energy on a "small thing" without addressing the relationship to the larger "problem"
TBL: would be happy if we pick two clusters, write list of straightforward questions to be answered.
... each one gets a general direction, someone goes and writes
... then review, and pipeline each issue
NM: i) who is audience? ii) metrics for success?
LMM: work products:
iii) slides, blog et al (education materials)
iv) formal rules of some form
LMM: useful to think about these categories against the reasons we would work on them
TVR: I would like to do that F2F today
LMM: ... and what would be the deliverables (base on the rough TAG work product list above)
NM: would like to get to prioritization ASAP
... when we start working on something, what are the metrics?
LMM: in coming AC Meeting is there no agenda place for TAG report?
... move to error handling
<trackbot> ISSUE-20 What should specifications say about error handling? notes added
(didn't want to add a note, but oh well)
NM: shepherd for ISSUE-20?
HT: I'll take it
NM: PROPOSAL - close ACTION-199
<DanC_lap> close action-199
<trackbot> ACTION-199 Follow up on error handling thread (8 Oct) closed
(reviewing thread on HTML and XML - http://lists.w3.org/Archives/Public/www-tag/2009Feb/0040.html)
HT: lot of well-formed problems occur at very lowest level
... ie. bad serialization code, not bad keystrokes
... see http://lists.w3.org/Archives/Public/www-tag/2009Feb/0060.html
... related to 3023bis
... should we ask XML Core to look at question of whether there should be a serialization spec to go with infoset spec?
... would such a spec. cause implementors to implement it?
... mostly this occurs in aggregators
... " pull things into a matrix, and then serialize it
NM: you're talking about XML, not HTML
... some say XML held up as a strawman - it's broken, should be fixed
HT: I attempted to summarize the email thread in response to my TAG-actioned email
... NM made good summary of the language/spec. behaviour distinction - http://lists.w3.org/Archives/Public/www-tag/2009Feb/0181.html
... lot of sub-issues and areas where work could be done
... XML serializers and output which is not well-formed
... Assertion that XML spec. does not define error handling
LMM: if something is an error, and then you specify some normative behaviour then it is no longer an error
HT: responsibility of conformance sections to say something about behaviour on error condition
NM: agrees with Larry, but there's more...
... you write a spce.
... agree what a legal doc is
... some things look like specifications for *code* not language
HT: does the TAG want to explore the narrow question of the XML treatment of errors?
... general question will keep coming back
... Opera drafted rewrite of the XML Stylesheet PI REC
... ... which discusses error recovery a la HTML5
... relation to tagsoup "just keep truckin" approach
... declarative spec. of error handling
... not work for TAG
... bridge the gap from XML issues to larger HTML issue
<DanC_lap> (I note, again, hsivonen implemented a subset of HTML 5 that can be parsed in one pass. I'd like to see that written up as a separate note or something.)
HT: there are HTML5 issues that tread on others
... language def vs. consumer behaviour are felt by many that it is useful to make orthogonal
... anything else?
LMM: would like to talk about scope of what we do here
... XML would fall within XMLCore, some would fall in HTML5 WG, some activities would be liason
... XML serialization issue sounds nice to solve
... should we talk to PHP implementors, for example?
<DanC_lap> (I still don't see goal #1 written down)
from above: HT: XML serializers and output which is not well-formed
LMM: what should specs say about error handling in general?
<Zakim> DanC_lap, you wanted to lump 6 (HTML) with 4 and to say, re "nobody on mobile," that it's part of a device-independent approach to web app security
<Zakim> noah, you wanted to talk about the big picture
NM: your (HTs) points seem very specific, which is good
... community is thrashing on view that HTML5 is on the right track
... grounding in reality of the moment is good
... but.... do we really want to wrestle with XML PIs?
... success is moving the community
... which is proving difficult
... we need to consider how to address the big picture
... so, what to do next?
LMM: general guideline about error behaviour
... in general better to write a spec to say that if you do this, good things will happen
... important to document why it is that XML specificies error behaviour of ill-formed content
TBL: you are defining what an XML doc serizialization is
... separate spec. to say if you find an error what to do about it (erro recocvery)
LMM: Postel's Law example - how does it fit here? (didn't get all of that)
NM: not customary in C community to blindly write bad code
... have a spec. that this is correct. Core language spec. doesn't say anything about what bad code "means"
<masinter> Postel law, robustness principle: conservative what you send, liberal in what you accept
<masinter> XML encourages parsers to *not* be liberal in what they accept
NM: if I'm writing something more like lint than a compiler, error recovery is more important
TVR: when writing such as program you don't need to say what is "bad code"
<masinter> Within the context of a browser run by an ordinary user, "Liberal in what you accept" is reasonable
TVR: lint doesn't need to recover, it's not running the code
<jar> a browser is not a compiler.
LMM: to be specific - we could come up with some writing about robustness, reasons why XML does what it does, relation between browser (processor very, very liberal)
<noah> I pointed out that compilers like gcc are doing two things 1) helping you to run correct programs and 2) helping you to diagnose problems in documents that aren't C-language after all.
LMM: reason that not everyone should be that liberal
<noah> Thus, gcc is processing two languages at once: the path that actually causes the program to run accepts only legal C; the other path processes a superset language.
LMM: how to say something useful about error-handling in a spec. in a general way
<jar> (JAR wants to insert a mention of Martin Rinard's work on error handling in embedded systems... will google for a URL)
LMM: we still want to encourage conservative senders
... even if receivers will be liberal
<timbl> Thanks for all the fish, Stuart.
NM: recognizes Stuart's help in getting him up to speed
<jar> (Rinard: Enhancing Availability and Security Through Failure-Oblivious Computing )
all: thanks, Stuart!
HT: as shepherd, I will attempt to take this feedback and structure it appropriately
LMM: will help
... role of robustness in language specs.
<jar> scribenice: jar
<jar> scribenick: jar
signs of convening...
<timbl> Adding a Url Scheme to a Qt Application Running on Mac Os X and Win32
Noah will propose at next telecon a procedure for putting inactive old issues to sleep.
Review of late / unscheduled agenda items
(reviewing bottom of agenda)
<ht> SCRIBE PLEASE NOTE: Link to this wrt this morning's discussion of error handling: http://www.ltg.ed.ac.uk/~ht/TAG_errorHandling_200903.html
Re use of CURIEs in RDFa: explicit request for TAG attention
ACTION johnk to read thread on RDFa, CURIEs and profile and summarize http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html
<trackbot> Sorry, couldn't find user - johnk
<scribe> ACTION: john to read thread on RDFa, CURIEs and profile and summarize http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html [recorded in http://www.w3.org/2009/03/05-tagmem-irc]
<trackbot> Created ACTION-240 - Read thread on RDFa, CURIEs and profile and summarize http://lists.w3.org/Archives/Public/www-tag/2009Feb/0295.html [on John Kemp - due 2009-03-12].
next: content type override 24
Noah will schedule telecon discussion of ISSUE-24.
Next: request for versioning input from HTML http://www.w3.org/html/wg/tracker/actions/108
<scribe> ACTION: Masinter to review TAG versioning situation and report back to TAG and HTML [recorded in http://www.w3.org/2009/03/05-tagmem-irc]
<trackbot> Created ACTION-241 - Review TAG versioning situation and report back to TAG and HTML [on Larry Masinter - due 2009-03-12].
<noah> LM: There's no need for Noah to schedule versioning discussion now
<masinter> i'll ask for a discussion after that review
next item: Mobile web? Noah happyt to defer
LM: We've been asked to consider mobile and multimodal web issues
raman: these two are separate
<masinter> not for TAG, on ac-forum as topic for W3C
next item: AWWSW - deferred
<DanC_lap> (I think mobile comes up everywhere rather than nowhere)
<DanC_lap> (esp security, HTML, error handling, etc.)
Next agendum: priority setting
noah: Sooner or later interest areas have to map to issues (perhaps new ones)
... In spreadsheet but not on whiteboard: what everyone was willing to work on
(noah sorts the spreadsheet by cluster)
lm: Suggestions: reasons why we're doing them, things that we can do. What kinds of products should result?
noah: Can you name 1-2 most important things in each cluster?
lm: In area A (HTML) there's quite a bit of liaison to be done
... priority is reducing conflict within W3C
... specific areas where findings would be useful, e.g. error handling
timbl: harmonize xhtml and html from DOM up - is most important
john: Education theme - just describe specifically what the issue is - is a good contribution
john: TAG is one; ... "a short recent history of versioning"
lm: trying to drive toward metrics (for evaluation)
<masinter> e.g., as a NOTE?
john: (other audiences) and the HTML group, others involved in these discussions
<johnk> a NOTE, if "approved" by the TAG
danc: I want to lay out distributed extensibility arguments in the ESW wiki. Each person says there piece over and over, would be good to collect on one page
john: Yes, this is similar to what I suggested (write down what we know)
<DanC_lap> (importantly, "we" includes both the TAG and the HTML WG; the esw wiki is neutral turf)
lm: Potential topic: Layering of protocol / media / scheme reference - orthogonality of schemes & protocols?
... spec layering is possible subject of a finding
... it could be useful.
<DanC_lap> (spec layering sounds like motherhood; i'm struggling to see how a finding there would help)
ht: Larry this morning volunteered to write in the area of Postel's law and exceptions...
lm: yes, that falls under exception handling
... Whether the role of non-W3C specifications, plugins, extensibility needs to be accounted for in web architecture
... ... not sure where that fits
ht: The missing action belongs here - either bridging gap, or media-type namespace defaulting thing, although larry didn't want us to call it that
... the gap between namespace aware and unaware languages
noah: Let's move on to cluster B (metadata access, http use)
... I will photograph the whiteboard
NOTE TO MINUTES EDITOR: ensure photo linked
<DanC_lap> and a text list of clusters: A HTML, B metdata access, ...
<johnk> A: HTML + XML
<johnk> B: Metadata Access + HTTP use
<DanC_lap> (my understanding of the Martin bug database example is that conneg is OK)
ht: Need to say succinctly an answer to the conneg use question...
ashok: There are RFCs in progress, let's wait and see?
noah: What do we want to deliver/achieve in this area?
timbl: Two things, firefighting and architecture
... Put in place a new piece of architecture saying here's how to do this
dorchard: Link header is web arch, not semantic web arch?
timbl: non-RDF uses of Link: are legacy
(someone): we'll be ignored if we say it's semweb
noah: We have 2 issues open. One about getting metadata, the other about 303
... Is the goal to help an RFC draft, or to solve community problem?
noah: Tactic: to help out with drafts
lm: There is significant concern with documents being outside of the organization. Independent review is less productive than a liaison activity. Review without meeting is not so good
danc: No one's suggesting this
ht: We have not established that it's great work
noah: What should TAG do (by way of process) - how/when to spend time on it
lm: Draft review can be private
john: Structure according to liaison, education, finding
lm: Everything around this is liaison
noah: What else to track?
ashok: Third part of this is site-meta
... JAR has useful summary ...
... Nobody has stood up and said X is wrong, should be done very differently
... questions of detail...
... help them get the 3 drafts right
ht: My memory was *not* that these were all on the right track. Prior goal: do we have consensus around the architectural soundness of the goals they're aiming for?
... We need to satisfy ourselves that these 3 documents are architecturally sound
lm: As a group?
ht: Yes. Documents from last year were a start for our own education
lm: What would we do to make our opinion known?
dorchard: Wish that the TAG would take an interest. Surface principles involved. E.g. Can an HTTP resource speak for an email address?
can http: be authoritative for mailto: ? "No" answer led to the DNS path...
<masinter> this is a large, hard problem, and a small finding will be confusing rather than helpful
<Zakim> masinter, you wanted to argue against TAG attacking this piecemeal
lm: This is a large hard problem, attacking it piecemeal is destructive
... For me this is lower priority
... Let's document that this is hard, lower priority, and punt
timbl: I don't agree. Yes, top down metadata is hard, but community has needs now
<masinter> no, i don't say 'punt'
<masinter> I think this is an important topic, just less important than a few other things
NOTE TO EDITOR: Masinter didn't say 'punt', that was scribe's word.
<masinter> counter-productive, not destructive
<johnk> C: URIs, Naming, Meaning of names
sorry larry. when i scribe i rephrase for expediency & take liberties
<masinter> I'd support a review meeting with the proponents, even if it was low priority
<DanC_lap> (yes, i recall a nice article by eran; i gather it's the basis of the requirements-evaluation appendix in his Internet Draft)
<masinter> it's fine, please proceed, i'll correct as I notice
noah: On to cluster C
What's goal for URNs and registries?
<DanC_lap> rephrasing isn't a character flaw; it's a natural part of scribing
ht: Success is, does it answer the question members came to us with, as we've interpreted it
<johnk> masinter: review meeting with which proponents? (see your comment above)
what are the tradeoffs in using http versus creating a new naming system
<masinter> (to whose satisfaction)
('naming system' is agnostic regarding how manifested, scheme vs. urn registration)
noah: SchemeProtocols - was confusing to me when I started with the TAG
lm: Can't argue against the desirability of this, have been involved in this for a long time
<DanC_lap> scribenick: DanC_lap
lm: I think this fails the "can complete" test.
NM: I have some experience in support of that
<masinter> 1999 presentation on "problems URIs don't solve, but think they should"
NM: while in the case of some hard problems it's obviously hard, in this case, many people think they know how it works, but they know different things; maybe explaining why it's hard to agree is worth doing
<masinter> i think the XRI discussion was foolish and the TAG should have refrained from giving a strong proposal
DO: we eventually decided to advocate against the XRI spec, though it took us too long to get there; I encourage the TAG to continue to [not sure I got it...]
<scribe> scribenick: jar
lm: I know the argument tree very well
... You're suggesting an educational activity?
ht: Yes. Maybe it fails at its goal
noah: Draft attempted to do both
... Anything else in this area [cluster C]?
lm: Strongly opposed to making this high priority
noah: If we can serve the community ...
lm: Can't imagine anything we write can be helpful
(observes general lack of consensus)
<masinter> anything *new* that we write, that's better than things that are already helpful
jar: I need to work on this... it will be helpful for me
dorchard: Larry, would you have agreed with XRI recommendation?
lm: Would not have agreed
<masinter> jar, I'm happy that you continue to work on it, and i'm willing to help, offline, i just don't think the TAG could be successful
dorchard: In my 7 years of experience, this was one of the few places where we changed someone else's work for the better
<masinter> a) I think XRI is irrelevant and not particularly significant, and b) it's not clear how much better
raman: Only time will tell what 'better' is
<johnk> D: Semantic Web Architecture
lm: Was there any part of semantic web architecture not covered by other clusters?
... Answer was specific vocabularies
(We have moved on cluster D, which is semantic web architecture)
<masinter> the category (D) "Semantic Web": what things weren't covered by (B) and (C)?
timbl: linked data synchronization?
lm: that was my attempt to scribe what someone said, not sure
timbl: AWWSW work is valuable - ontology for HTTP so we stop arguing about what 'representation' means [etc.]
... RDF-izing webarch is a tool that we can use
lm: Doesn't know what AWWSW is about
<trackbot> ACTION-201 -- Jonathan Rees to report on status of AWWSW discussions -- due 2009-03-30 -- OPEN
timbl: Possible TAG activity - use AWWSW output as building block in some new document
<DanC_lap> action-201: http://esw.w3.org/topic/AwwswHome
<trackbot> ACTION-201 Report on status of AWWSW discussions notes added
ht: You haven't suggested this before - the idea to reissue to formalize
<DanC_lap> odd... "This is an informal group; it has no particular charter."; i thought it was chartered by the TAG. I think I can find records...
timbl: It would be volume 2, not a revision
lm: If there's a separate AWWSW group, shouldn't they be the primary mover on this work?
noah: Is it in their scope to do new AWWW work?
<masinter> for [b] and [c] as well as [d]
noah: On to cluster E - security
noah: This is a broad bumper sticker. Are there concrete proposals?
noah: Not an activity / action
timbl: E.g. someone would review and track these outside activities
... E.g. someone would track cross-site scripting issues
<masinter> Security should be built into AWWW
<masinter> Liaison should expose design problems which cause security problems later
johnk: There are so many groups working in this area: origin header etc
<masinter> working groups currently don't take security as a first requirement
johnk: Would be good to understand the general picture first
<masinter> security should be than accessibility
<masinter> liaison with IETF Security directorate, signal sign-on etc.
johnk: origin = barth and hickson
<DanC_lap> (I updated http://esw.w3.org/topic/AwwswHome to refer to http://www.w3.org/2001/tag/2007/11/05-afternoon-minutes near "task force of the TAG" and removed "no particular charter". perhaps there's not much of a charter, but "no particular charter" suggests there's no formal connection to the TAG)
timbl: anti-phishing - authentication - lots of stuff falls under security
lm: security is a general architectural issue that we tend to address late
<DanC_lap> (which WGs don't take take security as a first requirement?)
lm: w3c has people proactive in other issues such as acessibility; security should have similar status [scribe license]
<johnk> Can we recommend 'security considerations' for all specs. in W3C?
<DanC_lap> (which existing security orgainzations do you have in mind, larry?)
lm: e.g. review AWWW against security requirements
... specific liaison with web security organizations
... anti-phishing work
... domain name spoofing, etc.
<Zakim> DanC_lap, you wanted to note http://www.w3.org/TR/html-design-principles/#secure-by-design
danc: I disagree that we don't think it's important
dorchard: we did do passwords in the clear finding
<masinter> independent of whether it was important in the past, the question is whether it's important going forward. It doesn't fit into any of the other clusters
ashok: Maybe the people interested should do some outreach [scribe license]
lm: Sorry for casting aspersions on past work of the tag... but security work doesn't seem to fall under other categories of TAG work
timbl: Attacks are not usually on the specs; they're on the ensemble. No algorithm will find flaws
<masinter> top 10 security problems lists -- lots of them
timbl: Immediate response from those who know this stuff is: Excuse me, talk to us, we know this
<DanC_lap> not sure this got captured:
<DanC_lap> LMM: security is perhaps the biggest threat to the Web reaching its full potential.
timbl: it's not clear that the TAG could by sheer will effectively address security
lm: I'm suggesting liaison, and to look at places where W3C isn't working but should be
timbl: constant vigilance
<Zakim> timbl, you wanted to expre some concert with hostmeta
<timbl> q was historical
<DanC_lap> (I'm sympathetic to LMM's point that there are these lists of security issues that don't get the attention they deserve around here; http://delicious.com/connolly/security is a sort of guilt-pile where I put stuff when I find it.)
noah: Seems success here might be influencing the AC. W3C does or doesn't have an investment in security activities; question is whether they're adequate
lm: Looking for areas where we could show technical leadership
johnk: Would like to have evidence - go out and talk to people
<johnk> ie. like evidence that TAG can really do something in this area, and clearly describe what that could be
noah: Mobile used to be like voice browsers - niche. But they're coming to dominate [scribe liberty]
johnk: F: Mobile
danc: There's lots of mobile stuff
<johnk> I have a sense that security is important and under-represented at the web-arch level,
raman: For a long time it was thought to be distinct - now they're converging
<johnk> but I also have the sense that there are many experts working here, both within and outside the w3c
<masinter> plea for multi-modal web focus http://lists.w3.org/Archives/Member/w3c-ac-forum/2009JanMar/0124.html
noah: Typical person building browser assumes keyboard/mouse. But now it's going to accelerometers etc
... Is there a standard way to get acccess to accelerometers?
danc: Yes, we had a workshop
... maybe we could spend time on the workshop report
<johnk> security for access to device APIs report - http://www.w3.org/2008/security-ws/report
<timbl> logger, pointer?
<trackbot> Created ACTION-242 - Inform the TAG about the mobile workshop report http://www.w3.org/2008/security-ws/report [on Dan Connolly - due 2009-03-12].
noah: Web-based solutions are one piece of the puzzle. Generic or platform specific?
<masinter> What "the web" is changing as the range of devices is extended, what W3C specs ....
noah: (missed, about relation of web to mobile devices)
lm: Look at orthogonality of core (shared) vs. non-core; have we abstracted properly
... Hard to see what the articulation points are if we consider [webarch] as one big spec
<masinter> location specification etc
<masinter> this is another area where most of the work is currently going on outside of W3C
<masinter> but they're not looking at the space from an architectural point of view
<masinter> and interaction with webarc and other elements aren't clear
raman: Is this [missed antecedent] a TAG issue?
noah: Can you do things through the web that you would expect these devices to be able to do?
danc: I'd love it if the platform guys would come tell us about their platform
<masinter> been some W3C non-success of device independence, etc., don't want to repeat the failures
danc: I'd be more comfortable with "device independence in the emergence of mobile"
<DanC_lap> platform guys, e.g. palm webos platform
lm: Most activity in this area is outside of W3C. A lot is not being done with an architectural point of view. It's a question, not assertion, are there ways we could modify webarch to enhance mobile devices?
... How do we get in front, without getting in the way? Liaison function
... Many things people tried were not successful
... We don't want to repeat this kind of work, but it be useful to understand why it didn't
... Can't think of anything to do other than liaison at this time
... I'm expecting our list of major topics as a statement from the TAG
<masinter> we're doing fact-finding and learning, and inviting community to bring up architectural issues
<masinter> and liaison
timbl: But no one has flagged issues in this area for the TAG?
ht: Didn't we get asked about the transforming proxy stuff?
<DanC_lap> (er... this list is going in our minutes; that doesn't seem to be a big statement. I wonder what big statement LMM has in mind.)
<masinter> i would like the TAG areas and prioriites to appear on the TAG home page
john: people see reasons to bend the architecture
<DanC_lap> ah. do you have CVS write access? do you know?
<johnk> (to masinter)
<johnk> DanC - me?
lm: When we've decided on priorities, home page should be changed to reflect them
The following links are to photographs of the issues collected on the flip charts during this discussion:
A transcription of the content of the flip charts is available at 05-whiteboard-priorities.txt.
<DanC_lap> well, was addressing masinter, but I'm happy for you to tidy the group page too, johnk
noah: Thanks to local arrangements / host Ashok
<masinter> would like shepherds to review open issues against the "reasons"/evaluation criteria -- can complete, long term value, producing artifacts, member/tpac interests, etc.
raman: Put 6-month inactive issues to sleep
ashok: Regrets for a telecon next week (March 12)
timbl: Regrets March 12
jar: Regrets March 19
<timbl> Regrets March 12, 19
<masinter> regrets March 26