See also: IRC log
<scribe> Scribe: Henry S. Thompson
<scribe> ScribeNick: ht
VQ: Roy is at risk, we won't wait for him
NH, HT: Revised minutes will take a day or two, but will appear
VQ: Next telcon: HT, NM regrets for Schema f2f
... TBL regrets, RF regrets
... One more regret and I will cancel, but with 5 we will try to go ahead
<DanC> I'm available to scribe 31 Jan
VQ: ER to scribe, DC fallback
<ht_> Proposed agenda for today:
VQ: Agenda agreed with Security Wkshp at the front and WSDL/RDF added at the back
<ht_> minutes of 10 Jan:
RESOLUTION: to adopt minutes 10 Jan
VQ: Activity summary due
<scribe> ACTION: VQ to prepare a summary in the next few days, circulate to tag@w3.org for review, then go public depending on feedback [recorded in http://www.w3.org/2006/01/24-tagmem-irc]
VQ: TP starts in one month, no joint meetings yet scheduled. . .
... What opportunities are we at risk of missing?
DC: Like to talk to Compound Document WG. . .
DO: Working with Hoylen Sue on XML Schema versioning stuff, hoping to work with Schema WG on that, also spooling up on our own versioning work
... So want to ask Schema WG to take part to go over the use cases, maybe get an updated draft finding in time
NM: XML Schema WG is not meeting at the Tech Plenary, meeting in Florida next week instead
... But in fact at least HST, NM, MSM will be in Mandelieu
VQ: Formal meeting with CDF WG?
DC: I don't think a formal meeting is required, happy to just talk informally
VQ: I wouldn't mind chatting with them. . .
<Zakim> noah, you wanted to mention binary WG
NM: I'd prefer to save formal meetings for times when we have formal business to do, so perhaps not this time for CDF
<DanC> (Noah, did you say we've met with the CDF WG before? I don't believe we have.)
HST believes we met CDF WG last year in Boston
NM: I don't have any particular item we need to talk to EXI about -- just pointing out that they're just starting up
<noah> EXI is meeting Thurs/Fri at the plenary, as I recall.
VQ: So doesn't sound like any formal meetings are required, but no reason this can't change in the intervening month. . .
<DanC> W3C Workshop on Transparency and Usability of Web Authentication 15/16 March 2006 New York City, USA
DC thinking about turning his contributions to this group on security into a position paper for this workshop
scribe: Digest authentication
DO: In our discussion about state, this has come up, and there's some discussion about forms-based security
... taking over from http-based security, in my draft finding about state
... Will find URI and paste here
DC: Haven't come up with a thesis statement for a paper
<Zakim> ht, you wanted to suggest a thesis
<dorchard> Rough text for State finding 15 Oct
HST: "We already know what we need to do, why aren't we doing it?"
TBL: I'm interested, but I can't fit it in
<dorchard> The primary reasons for customized security are security concerns, that
<dorchard> is wanting greater control over the security timing out, and ease of use
<dorchard> concerns, particularly wanting direct control over the look and feel of
<dorchard> the screens including helpful tips and links to forgotten passwords.
TBL: I have a UK trip already scheduled for that week, which is a shame
DO: Not in the same direction as HST's digest authentication suggestion -- my thesis is we don't have what we need
TBL: Just display the name of the holder of the certificate in the browser, half the phishing stuff would go away
DO: People want control of the look and feel, timing out, etc.
VQ: So, nothing for this group?
DC: I've got helpful input, all I was hoping for, not planning to represent the TAG if I go
VQ: OK, nothing more to say
<DanC> aha! finally found it...
<DanC> minutes of our security discussion
<ht_> Reply from WS Addressing WG wrt epr-47
<noah> Our original proposed text:
<noah> Note: Web Architecture dictates that resources should be identified with
<noah> URIs. Thus, use of the abstract properties of an EPR other than
<noah> wsa:address to identify resources is contrary to Web Architecture. In
<noah> certain circumstances, use of such additional properties may be convenient
<noah> or beneficial, perhaps due to the availability of QName-based tools. When
<noah> building systems that violate this principle, care must be taken to weigh
<noah> the tradeoffs inherent in deploying resources that are not on the Web.
VQ: WG has modified their document, asking for our feedback
<noah> Their proposal:
<noah> The Architecture of the World Wide Web, Volume One [AoWWW]
<noah> recommends [Section 2 of AoWWW] the use of URIs to identify
<noah> resources. Using abstract properties of an EPR other than
<noah> [destination] to identify resources is contrary to this
<noah> recommendation. In certain circumstances, such a use of additional
<noah> properties may be convenient or beneficial; however, when building
<noah> systems, the benefits or convenience of identifying a resource using
<noah> reference parameters should be carefully weighed against the
<noah> benefits of identifying a resource solely by URI as explained in
<noah> [Section 2.
<noah> The Architecture of the World Wide Web, Volume One [AoWWW]
<noah> recommends [Section 2 of AoWWW] the use of URIs to identify
<noah> resources. Using abstract properties of an EPR other than
<noah> [destination] to identify resources is contrary to this
<noah> recommendation. In certain circumstances, such a use of additional
<noah> properties may be convenient or beneficial; however, when building
<noah> systems, the benefits or convenience of identifying a resource using
<noah> reference parameters should be carefully weighed against the
<noah> benefits of identifying a resource solely by URI as explained in
<noah> [Section 2.
<noah> [Section 2.1] of the Web Architecture.
NM: We could quibble -- they toned things down a bit, we could push back, but I think it's a straight yes-no call
DC: I can't see the difference . . .
... I've seen various drafts, can't tell the difference any more
TBL: I don't see anything worth fighting about there
DC: What about the example?
<noah> Our note to WSA
HST: I think that was an illustration for their benefit, not suggested for inclusion in their REC
... I think their proposal represents some positive movement on their part, should accept with thanks
DO: +1
DC: I'd like to think a bit out loud about this before agreeing
... Were we trying to change the world, or just get some words in the doc't
DO: I wanted us to change the world, in the direction of proposing encoding of EPRs in URIs, but we haven't gone there
NM: [scribe missed some]
... DO helped us in E'burgh to see what some of the reasonable motivations were for using EPR parameters for despatching
... So rather than just saying to WSAWG "don't go there", we decided to try to get acknowledgement of the costs as well as the benefits
DC: Was there a GRID spec that uses EPRs?
NM, HST: WSRF
TBL: Worried none-the-less that we'll start seeing EPRs turning up as the only identifier for some resources
DO: I still think we should push for EPR-in-URI work, maybe from WSA WG, maybe with help from us
... Until that happens, as long as dispatching on QNames isn't addressed, people will use EPRs
DC: Thanks, that has helped
<DanC> (I wonder if WS-RF is done, or still asking under review. I get "done" vibes from http://www.globus.org/wsrf/ )
NM: I'm concerned about the meta-question of scenarios in which a WG is doing something (SOAP endpoints, WSDL component naming, WSA and EPRs) where TAG feels more should be done -- how should we deal with this
... I think this should be made more explicit in group charters, so that they're not surprised/upset when we come to them
DO: I think we are there with XMLP, WSDL did the HTTP binding for us, contributed to the schedule slip for WSDL2.0
... WSA is moving much faster, maybe that's because they _didn't_ take so much care about WebArch issues
<Zakim> DanC, you wanted to suggest 1st WG ftf as a time to expose WGs to webarch, no just charter, and to think again about CDF, EXI
DO: Certainly agree that if we're going to enforce expectations about WebArch on groups, we should signal that early
DC: Doing it via the charter is not clearly the best route, rather get it in the culture at their first f2f. . .
NM: We could consider internal guidelines -- e.g. when people say "Hey, do some RDF for that too", are you allowed to ignore that, or is it obligatory, or . . .
... People are legitimately confused about how this all applies to their WG
... They need help getting a consistent reading on this stuff
VQ: The agenda item is not about this general issue
<DanC> (yes, back to the proposal to accept this wording with thanks.)
VQ: So how do we reply to their proposed text?
... I think I hear consensus that they've done a good thing, as far as it goes.
RESOLUTION: We are satisfied with the text they propose to add
<scribe> ACTION: NM to convey this to the WSA WG [recorded in http://www.w3.org/2006/01/24-tagmem-irc]
HST: Perhaps the meta-topic would be a good agenda item for the f2f
VQ: Roy has left the call. . .
<ht_> RF's pending actions:
<ht_> Roy's summary of his situation
VQ: wrt metadataInURI-31, no progress, RF suggests to drop the action
... NM was involved too -- Noah?
NM: I've been trying to uncover the history, I get added to this late in the game, don't really know the history
... Haven't made any progress -- we should assume it has fallen through the cracks
... I would prefer to get off the hook on this to focus on other issues on my plate
DC: I'm torn about this
TBL: Related to URIGoodPractices-40
<noah> Draft
DO: URIGP-40 was just a response to RF's assertion that parentheses are bad in fragIDs, we can let that go
... but mIU-31 is more serious
NM: I see we have a draft from Stewart, but I can't tell why it didn't go forward. . .
DO: I think there's lots of good stuff in there
NM: I asked because if there's broad agreement on what's there I'm more sanguine about taking it on
<Zakim> ht, you wanted to mention persistent identifiers
<timbl> - HTML forms
NM: But if people aren't clear about where we are
HST: The InfSci community cares about this, it's one of the reasons they keep inventing new URI schemes
<DanC> issue metadataInURI-31
HST: But I don't have much time now to help move the issue forward, don't even know what the draft says
<DanC> (my hazy recollection of stuart's draft is that it's too long)
DC: I feel similarly, would pick it up if it were going to drop altogether, but that wouldn't get it moving any time soon
NM: I can pick this up, but it will go on the queue behind other things
... but again, no time soon
DC: Don't drop the issue, but drop all the actions against it
DO: I think this is _more_ important than schemeProtocols
VQ: We can't leave actions pending against people who have left
<noah> NM: Actually, I can also pick this up and put it ahead of schemeProtocols
VQ: So let's withdraw the action wrt mIU-31 against his name
<noah> DO: Yes, ahead of schemeProtocols
<DanC> (I'd suggest dropping the action on SW similarly)
NM: I need guidance on relative priority soon
HST: See DC's suggestion
VQ: OK, will do that too
<noah> NM: I.e. I'm about to turn back to schemeProtocols as PLP settles down (I hope). If the group prefers I do metadataInURI first, then I'd rather know that before I swap SchemeProtocols back in. Thanks.
<noah> VQ: Noah, settle it in email?
<noah> NM: fine, thanks.
VQ: so, next action on RF's list is putMediaType-38
<DanC> +1 continue
VQ: RF promises to deliver final draft in Mandelieu at the end of February
... Next one is uriGP-40
<Norm> Get Roy to deliver his action!
<Norm> :)
VQ: RF does not expect he would get consensus for whatever he wrote
DC: Let's remove this from the issues list
... Covered elsewhere, I won't miss it
VQ: Others happy with that?
HST: Yes
(it was RESOLVED: uriGoodPractice-40 is to be removed from the list, but we later recinded that decision)
VQ: Usual announcement?
TBL: We need to leave pointers for posterity
DO: I don't think the () issue exists elsewhere, will just get lost
DC: I'm happy for it be lost until someone cares enough to pick it up
DO: History is that in the discussion of abstractComponentRefs-?? when XML Schema WG/WSDL WG said they would use XPointer, RF said "(), bleuch", so we raised a new issue
... We closed aCR-37
DC: Hold on, aCR-37 is open
DO: We told the WSDL WG we were not going to push back further on this point
... I think these two issues are orthogonal and should be treated as such
<timbl> Where does it say why not to use () ?
<DanC> nowhere
<DanC> on the contrary; XPointer, a W3C Recommendation, says _to_ use ()s
DO: As long as we're happy that people can use ()s in fragids, we don't need this issue
<timbl> Let us write soemwhere taht it is a bad idea becaus eyou can't use qname-like shorthand for them.
DO: If that ever becomes a problem, then we should come back to this
TBL: So QNames were iintroduced to minimize the burden of long URIs, but ()s in fragids render this solution unavailble
HST: I agree with DanC -- that issue, i.e. should any kind of fragIDs other than barenames be avoided, because they bar the use of QNames, is being discussed regularly by the TAG under other headings
VQ: DO, are you happy for this issue to be dropped
<timbl> Let's keep the issue.
DO: I think it was important to separate out from aCR-37, because it's orthogonal
DC: I don't agree it's orthogonal, but I don't care about it, either
TBL: Move to 'someday' pile
<DanC> (I'm happy to leave 40 around until 37 is closed)
DO: OK, remove all actions against it, leave it rest until someone feels we need to resurrect it
VQ: To conclude, no consensus to drop the issue, we need to leave that for now
... For the sake of a clear history, we'll keep it open, but remove all pending actions
RESOLUTION: Remove pending actions on RF wrt uriGP-40
[supersedes previous resolution wrt uriGP-40]
VQ: That's it for RF's outstanding actions
VQ: In Norm's absence, let's postpone this to a subsequent meeting
<ht_> New draft
<noah> 32 Jan draft
<DanC> (tim, did you realize you wrote DesignIssues/Meaning , re xmlFunctions-34 and self-describing web?)
<noah> To do list and completed actions
NM: Appendix in the doc tracks my todo list
... Reordered the flow, cleaned up some details (SQL Turing complete?), security concerns, what _is_ Turing completeness
... Comment that there are downsides -- too simple isn't good either (Occam lives)
... RDF discussion untangled from HTML discussion
... Hope this is close to ready to ship
<Zakim> DanC, you wanted to ask why the principle is in a GPN box, twice
DC: Why not a principle?
NM: I could see it go either way
... Willing to change it
... Clerical error, I suspect
TBL: It's definitely a principle
<noah> Good Practice: When publishing on the Web, choose the least powerful or most easily analyzed language variant that's suitable for the purpose.
NM: What about the added one about scalable
HST prefers GP for that
DC: That one _is_ phrased as a GP
... task is to get the first one into a non-imperative form
TBL: Right, rephrase it to make it look like a principle
<timbl> The more powerful the language the less reusable the information.
DC: Other stuff is good
... Scope creep is a risk
NM: Yes, everybody wants to add a bit more
DC: Confirmed: the second box is to be left as a GP, but the first box needs to be a Principle
<DanC> PROPOSED: to approve leastPower-2006-01-23 + change 1st GPN to principle, contingent on thumbs up by @@(me? DanC?)
NM: I can make that small change in a day or two
DC: I'm happy to make a decision today
HST: Not ready to approve sight-unseen, sorry
NM: Target is consensus two weeks today, pending new sentence in email/new draft by the end of the week
<scribe> ACTION: NM to circulate revised sentence for the Principle by Friday 27 [recorded in http://www.w3.org/2006/01/24-tagmem-irc]
<DanC> (The biggest risk is that nobody will look at the revision right away, and then we'll forget in 2 weeks, and then noah will forget to change the GPN to a principle again ;-)
VQ: Nearing the end of the call -- we will come back WSDL/RDF next week
<noah> I think Tim's proposal of "The more powerful the language the less reusable the information." seems right, or at least very close.
<noah> I'll start with that and noodle on it.
DC: Two weeks, because TBL is critical resource