2. Approval of minutes from 21 Jan

3. Administrative items

Noah: prioritizing agenda: good news in that there is work happening. difficulty getting balance.
... request: TAG members active in a discussion, please step up and moderate discussion to reach conclusion, summarize different positions, etc.

5. W3C TAG position on policy mechanisms for Web APIs and Services

<noah> The DAP WG is only beginning to consider the privacy topic and would appreciate all help it can obtain from anyone that can help us achieve a good practical result in a reasonable time. Our initial starting point will be to examine the decision of the Geolocation Working Group in more detail. [...describes a proposal...] While we intend to look at each of the assertions made in that resolution and see if and how they would apply to our own set of APIs, we would very much welcome the TAG’s perspective on that resolution

<scribe> scribenick: noah

LM: There was significant unhappiness with geolocation resolution, and I think we should say it's not a good precedent.

DKA: When I sat in on the first working group meeting as an observer, not sure I can concur

LM: Don't concur there was unhappiness?

Noah thinks LM meant "the TAG was unhappy"

LM: There was a letter from IETF, and formal objections from Cisco and Center for Privacy and Freedo

DKA: I spoke to the area director for IETF recently.

<DanC> "the TAG was unhappy" needs a pointer to records. I'm pretty sure the TAG hasn't decided anything in this space

noah: Right, Dan. My recollection is that we had discussion of the unhappiness of TAG members. I also think we did send an email, but not sure "unhappiness" quite characterizes what that email said. Can't find reference now. Can anyone?

<scribe> scribenick: masinter

dka: there was a meeting. The browser vendors, Google, and our opinions were that it was inappropriate things to put privacy hooks into the API
... the input from the EFP and GeoPriv working group was taken very seriously by the group chairs, and there was a lot of text put into the document. I wasn't a direct participant but I was mentoring someone who was, and my understanding was there was a lot of outreach. Still we got a formal objection.

<Zakim> DanC, you wanted to ask whether this decision predates those objections

danc: Did the Geolocation decision (see the email we've been reading) come before the IETF letter, or vice versa?

DC: Trying to figure out if the asserted "unhappiness" is cause or effect

dka: i think it was last call, and it was not a single decision in the GeoLocation working group resolution

(discussion about chronology)

<DanC> I concur with "don't generalize"

LM: What i am trying to say is that the GeoLocation decision was reached after much discussion which seemed to be localized to a single decision about a single API to access a single bit of information: geographic location. Because this was so finely argued and the compromise reached after much discussion and contextualized, the Device API working group should not use this decision as a precedent.

danc: Frederick Hirsch seems to be happy with the email exchange, are we done?

noah: gets back to question. His note says:

<noah> From Frederick's note: "Our initial starting point will be to examine the decision of the Geolocation Working Group in more detail. This decision was *not* to include privacy rules as part of the API. That decision is documented with the following Geolocation WG resolution:

noah: what he's saying that we're taking this as a possible starting point. Some of us weighed in and the TAG discussed it.
... we could more formally say something as the TAG, given the concerns, the TAG wishes to signal real reservations

LM: I met at the IETF in Stockholm with IETF area directors and WG chairs. They were concerned. Part of that discussion was that compromise might be reached in this case, but it should not be taken as a good prededent.

noah: I have suggested several times: if you're not going to put it in the API, show that your API has sufficient extensibility mechanism, possibly those that allow you to decide whether extensions are present.... and show how this can be used. (noah explains details of how this can be written).

naoh: I'd be unhappy if the document did not at least talk about that.

dka: on the issue of what we tell Frederick, it's appropriate to say that you should not take this as a precedent. There are some specific technical reservations that Google, Opera and Mozilla have to the kind of approach that Noah is suggesting, that essentially boil down to something that is non-enforcable

noah: worth noting, but shouldn't resolve this

<DanC> (stronger than "not enforceable"; as I recall, it was "misleading")

noah: Want ask DanA with help from Larry to draft a short response that you think the TAG should send.

<trackbot> Created ACTION-380 - Draft response to Fredrick, short and to the point. Larry to review. [on Daniel Appelquist - due 2010-02-04].

note: Daniel in tracker is DKA

4. ACTION-351 Workshop on persistence

ht: We've been talking off and on since last summer's F2F about persistent domain names as one component of the reservations people have about using URIs for persistent identifiers
... 100 years for now if W3C doesn't exist and MIT screws up, W3C documents won't be available at their well-known address. We've discussed many solutions, including new IANA top level domain, or creating some public body to insure the persistence of these domain names. At our discussion in December consensus was we shouldn't take this on, and that we should hold a workshop.
... have spoken to director of Digital Curation Centre

6. Authoritative metadata

(postponing because JK not here)

7. TAG Contributions to W3C Web Site

<noah> Ian sent a note asking if TAG want to contribute to new W3C Web Site content: "Another of the 7 areas is "Web Architecture" [3]. We've not yet had the opportunity to flesh out the introduction pages that are linked from there. Right now, the titles of those intros (drawn from Webarch):

<noah> Architecture Principles

<noah> Identifiers

<noah> Protocols

<noah> Meta Formats

<noah> Protocol and Meta Format Considerations

<noah> Internationalization (already done by Richard Ishida)

noah: That structure reflects the WebArch document.
... We talked about this at an early meeeting but didn't find the resoures to do it

<noah> I also said I thought not just any resource will do. We need people who can write for some particular audience(s), write it well, etc.

noah: this is where people come to talk about the web. Would the TAG like to help the W3C tells the story
... if we could allocate the person-months of writing skill etc.
... seeing these things done well is person-weeks or person-months

<jar> masinter: another approach is to start with what they have and improve it

LM: htmlwg was going to close the issue, but i asked that it stay open to allow the TAG to volunteer to produce a change proposal
... they don't need us to produce the proposal by tomorrow, just for someone to commit to producing one that meets the criteria for change proposals.

DC: I made some progress. Between me and Noah we didn't get it on the agenda for today. I could work on it, but promising dates is hard.

NM: Implicitly, not for tomorrow?

LM: By tomorrow, we just need a committed date.

DC: Maybe we can pick a date.

LM: How about March 31, after our next F2F?

DC: Wonder if they'll accept that.

LM: Well, the concern expressed was that Roy couldn't even start for 4 months.