W3C | TAG | Previous: 2 Jun teleconference | Next: 16 June 2003 teleconf

Minutes of 9 June 2003 TAG teleconference

Nearby: IRC log |Teleconference details · issues list · www-tag archive

Note: The Chair does not expect the agenda to change after close of business (Boston time) Thursday of this week.

1. Administrative

  1. Roll. All present: SW (Chair), TBL, DC, TB, DO, RF, CL, PC, NW, IJ (Scribe)
  2. Accepted minutes of 12 May teleconf and 2 Jun teleconference
  3. Accepted this agenda, with addition of item on W3C/IETF meeting
  4. Next meeting: 16 June. Regrets: PC

1.2 W3C/IETF meeting

[Ian]

DC: IETF/W3C teleconf is 17 June. Might talk about mime types. Do you want anything on that agenda?
TB: We wanted them to provide web space and canonical URIs for mime types.
[TBray]
where's that IANA/IETF mime-type directory?
[Ian]
DC: Maintaining "tidy uris" - promise to keep http URIs to mime types and to give 1 year notice if they will change. Another issue is I18N URIs.
[Zakim]
Chris, you wanted to ask abou IDNA and process stuff and to also ask about URI mime registry and correct forum
[Ian]
CL: Is talking to Ned Freed the correct forum for pushing for tidy URIs?
[CL has an action item]
DC: Norm in IETF is to address author. In general, ok to cc public w3c/ietf mailing list
CL clarifying: Is our action the same?
TB: As I recall, DC had sent us a place in IETF land where all the mime types were on one page. However, as I recall, it was only really halfway there.
Example: http://www.iana.org/assignments/media-types/image/cgm
TB: I think CL had accurately described the pbs in his email:
Message-ID: <10684031578.20030228173630@w3.org>
To: webmaster@iana.org, CC: www-tag@w3.org, ned.freed@mrochek.com
DC: Ned is editing the policy that says they have to do it right. Make it policy through Ned Freed.
CL: I'll forward to w3c/ietf liaison list: public-ietf-w3c@w3.org
[DanC]
if you mail me about IETF/W3C business, pls copy public-ietf-w3c@w3.org
[Ian]
DC: Please read NF's policy document.
CL: I have read that.
DC: I pinged him to make a new draft; hoping he'll have one by 17 June
CL: What about i18n domain names?
RF: I18N domain names are done: IDNA is done; see RFC 3490 (Internationalizing Domain Names in Applications (IDNA)) and 3491. Both Standards Track.
SW: What about talking about URLs/URNs at 17 June mtg?
DC: No urgency for 17 June meeting
[TBray]
URL = Universal Republic of Love
[Chris]
URI=URL+URC+URN
URN=not liked, URC=not implemented, thus URI== URL
qed
[TBray]
neat trick since URL and URC don't exist...
[Chris]
oh, *minor* issue of detail ;-)
[DanC]
hmm... the xml.gov interaction didn't bubble up into an issue? oops.
[Ian]
DC: I can tell the IETF that we have some activity going on around this topic (though no formal issue).

2. Technical

2.1 Architecture document

The TAG expects to pick up where it left off (approximately section 3.2) and to complete its walk-through of the Arch Doc.

  1. 26 Mar 2003 Working Draft of Arch Doc:
    1. Action DC 2003/01/27: write two pages on correct and incorrect application of REST to an actual web page design. DC requests to withdraw this one.
    2. Action DO 2003/01/27: Please send writings regarding Web services to tag@w3.org. DO grants DC license to cut and paste and put into DC writing.
    3. Action DC 2003/03/17: : Write some text for interactions chapter of arch doc related to message passing, a dual of shared state. DC refers us to Conversations and State

Actions from 2 June meeting:

  1. RF to rewrite section 5. Section 5 is expected to be short.
  2. TB to rewrite section 4 based on his proposal for rewriting section 4and suggestions from the TAG from 2 Jun teleconf. (Done)
  3. CL to make available a draft finding on content/presentation.
  4. DO to update description of issue abstractComponentRefs-37
  5. SW: to continue work on and make available a draft finding related to the opacity of URIs.
  6. NW: Take a stab at proposed new 4.5, wherever it ends up.
  7. DO: Write up a couple of paragraphs on extensibility for section 4.
  8. IJ: to start incorporating detailed suggestions on Arch Doc made by the TAG (see IRC log for details)
[Ian]
[Reviewing where we were in 3.1]
At end of meeting last week we were talking about references to 2396bis.
CL: I request that we ignore IRIEverywhere-27 for this teleconf. I expect to send in some clarifying material soon.
RF: Move the IRI bit at the end of 3.1 (whatever it says) to a "Future directions" section for this leg of the tripod.
[Some agreement]
[3.2 URI Schemes]
RF: I rewrote this in 2396bis. Looks like first three paras of arch doc (but more accurate than arch doc). Text in rfc2396bis is more specific about role of schemes.
DC: I'm not thrilled about idea of cutting the text.
RF: I suggest reusing RFC2396bis text and including reference.
TB/PC: Why redundancy here valuable?
[Roy]
http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html#scheme
[Ian]
DC: The URI draft says "mailto scheme for email addresses" but says that "news is for usenet groups/articles". Please harmonize types in the list of examples in RFC2396bis (e.g., mailboxes/files/newsgroups).
[Roy]
Each URI begins with a scheme name that refers to a specification for assigning identifiers within that scheme. As such, the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.
[Ian]
RF: More specific - "URIs ARE classified by scheme"
[Chris]
sounds like keyboard/mic too near desk issues
[Ian]
Action IJ: compare 3.2 text with RFC2396 version 3; compare and harmonize; leaving about the same amount of text.
TB: In section 3.2, important thing is "New URI schemes". SO make sure that: (1) reader understands what a scheme is (2) reader has correct reference to URI spec.
RF: I think TBL and perhaps DC would like to emphasize the para I copied in - in the sense that one specification leads to another....
[DanC]
er... "layering"?
[Ian]
TB: Problematic to use myscheme: blort since there's no place to go look for it.
[Roy]
yep, layered specifications
[Ian]
[Discussion about new URI schemes]
DC: They are extensible, locally (e.g., on my machine)
DC: We don't have a cogent argument in our doc against creation of new uri schemes. E.g., if you are Apple, deploying new URI schemes is easy (since Apple controls desktop).
[Chris]
would writing an rfc saying 'this is http spelled different' make it non-proprietary
[DanC]
yes, bray's got it right here... 'if it has an existing name, use that name' derivable from network-effects principle
[Ian]
TB: I think the apple thing is a test case. The reason it's the wrong thing do to is that the information is available by HTTP (music store responds to http requests). Despite that fact they identified with a new URI scheme. It's bad since I could have shared HTTP uri with more people.
[Chris]
okay. what if its a defined http subset, like a get-only
[Ian]
DC: "If it has an existing name, use it." This derives from the network effect principle.
[Roy]
We should focus on the need to register new schemes and the built-in reluctance in the IETF to allow registrations of schemes that do not add value over existing set.
[Zakim]
DanC, you wanted to comment on examples and to and to riff on multi-party motivation
[Ian]
DC: Apple should have keyed off of mime type. But in the calendar case, they wanted people to put ics files on the Web. Think globally.
CL: Perhaps one reason they did this was to subset HTTP. That would be an advantage to a new scheme.
[Roy]
Answer: no, they wanted webdav URI as well.
[Ian]
PC: What special processing do these scheme resources get?
[tim_mit]
webcal: is of course similar
[Ian]
TB: I'm pretty convinced that there's no difference. Most of the xml downloaded (before encryption) had to do with presentation.
[DanC]
wierd! why is "only two tags, key and value" stupid, but RPV is better than RDF/XML syntax?!?!?!
[tim_mit]
??
[Ian]
TB: They should have published standard HTTP URIs for these resources and registered a mime type for the weird xml.
PC: So we are saying - don't create URI scheme; register your mime type.
RF: The registration process for URI schemes is being revised. In any case, we should emphasize in this section that the URI schemes have to be registered. Part of the registration process for URI schemes is MORE STRICT than the one for mime types.
[DanC]
strict registration process for schemes won't make them more likely to get registered. :-{
[Zakim]
Chris, you wanted to point out that new schemes fits with rhe upcoming component extensions work
[Ian]
RF: IETF rejects proposed schemes if deemed that they serve no useful purpose.
CL: Component extensions work at W3C.
[TBray]
Rumor is that they did this because Safari's mime-type dispatching is horribly inflexible
[Roy]
yes, webdav: was rejected for that reason
[Zakim]
tim_mit, you wanted to discuss why it is harder to do it with a new mime type, and therefore to suggest comments on the software architecture which follows.
[DanC]
which scenario are you speaking to, timbl? webcal: or items:?
[Roy]
DAV: was not rejected
[Ian]
TBL: It comes down to your software architecture. A typical dispatcher either (1) munges internally or (2) downloads and figures out what software to run on it. Apple registry may split "application" v. "extension" (like old days)
[DanC]
aha! of course! we need http-head://www.w3.org/ vs. http://www.w3.org/ , right, Ian? ;-)
[Ian]
TBL: One problem is two links that refer to the same thing (e.g., webcal v. http URIs which mean different things (different verbs for different uri schemes))
[Roy]
How does this discussion result in text for webarch?
[DanC]
the subscribe vs. copy choice is much like the "new window" vs "new tab" vs same-window choice.
[Chris]
it relates to 'don't make new schemes unless you need to'
[Ian]
TB summarizing:
  1. Gratuitous invention of URI schemes is not a good idea.
  2. State what the decision criteria are that would strengthen or weaken the attractiveness of a new URI scheme.
[Chris]
it still sounds like different schems, like get vs something else, to me
subscribe is clearly having a side effect and should not use get method
[tim_mit]
2) Gratuitous invention of RDF is not a good idea. On these two laws hang all the law and the prophets. ;-)
[Ian]
TB: The interaction in apple case is HTTP; no functions required that can't be done in HTTP; and wider applicability a good thing => use HTTP uri scheme. If you want a URI and if scheme exists that meets your needs and
there is a requirement for usage across wide range of users/applications, then don't invent new one.
SW: Any value in enumerating what the costs are?
TB: Even if URI being invented for private reasons, usually one finds public reasons.
IJ: Point to deep linking finding as well (basically "Keep your options open."). Sell it as a benefit - this keeps your options open!
[Zakim]
tim_mit, you wanted to suggest text for document along the lines that "Client-side flexibility in the dispatching of new MIME types should be suficiently powerful to allow new
... MIME types to introduce the necessary functionality"
[Ian]
[TBL: They could have introduced itunes as a sherlock plug-in]
TBL say:
  1. Dispatching on mime types is a useful thing
  2. We should write up the webcal story or the itunes story in a finding.
Explain why you lose when you do it that way (itunes or webcal)
[DanC]
hear hear. stories to supplement principles
[Ian]
IJ:
  1. Identify different ways of achieving extensibility
  2. Relative costs
TBL: Can we have a finding on this? Can TB provide this text as a finding?
TB: Sure, go ahead.
DC: Tell a story in the finding and seek a balance between finding an arch doc.
[TBray]
but no more XML (sob): http://www.tbray.org/ongoing/When/200x/2003/05/14/AppleShutdown
[Ian]
Action IJ: Turn TB apple story into a finding.
RF: On editor's note at end of 3.2? I think we should talk about this, and that it should be in another section.
[this = authority component]
RF: Somewhere we should talk about how URIs are allocated. Some are allocated using their own mechanisms; most are via authority delegation. See 3.2 of RFC2396bis for info about authority info. URI spec doesn't really talk about the social aspects of delegating name allocation. We should probably create a new toplevel section (3.x) on name allocation.
IJ: I'd like to make connection between meaning of resource and authority over that meaning.
[Ian]
RF: "Allocating URIs"
Action IJ: add a new 3.x section on allocating URIs; taking some text from rfc2396bis/3.2 and expanding slightly on social aspects.
[Break]
[Ian]
[3.3. Fragment identifiers]
TB: There's lots of new stuff in rfc2396bis. See section 3.5 Notion of a "Secondary Resource" : "The fragment identifier component allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is selective within that resource."
TBL: I don't like the piece in the arch doc about "part or view"
Action IJ: Integrate RF's 3.5 into from RFC2396bis into arch doc section 3.3.
TB: For RF's 3.5, there are some issues related to RDF. I'll send some text; I think people will disagree with "frag id identifies something selective within a resource"
IJ: Recall that I will be trying to keep one story throughout arch doc; I will probably do some combination of RF text + adding to the first scenario in the arch doc.
[DanC]
before leaving RFC2396bis, shall we acknowledge RoyF's 2 week 'last call' ish new-issue deadline, please, Norm/Stuart?
[Norm]
Yes, DanC
[Ian]
TBL (about RFC2396bis) : The secondary resource (identified by a thing with a #) is, like the primary resource, is determined by the naming authority. There should be consistency between primary and secondary resources. Just because you may not have a representation yet; the resource still exists.
RF to TBL: Please read 3.5 soon to let me know if you're happy.
RF about RFC2396bis: If draft hasn't changed in 2 weeks, then submitted to IESG for last call (for an internet-wide last call). I don't expect technical changes at this point. If there are minor wording changes, I'll produce a version 04 and then there will be an immediate draft to IESG. PLEASE make comments soon (within 2 week, ending 23 June).
[DanC]
RFs request was ackowledged by the chair.
[tim_mit]
TBL: There should be consistency between the idenity of primary and secondary according to the authority and any infromation returned in response to the dereferencing of the primary URI.
[Ian]
[3.4. Dereferencing a URI]
DC: Status of metadataInURI-31?
SW: I did a first draft of finding; haven't worked on it lately. There are various observers of URIs (e.g., origin server) and various parts of URIs that may be more or less opaque depending on the observer.
DC: Is your expectation of having finding done by end of June?
SW: I'd like to have finding in shape for our July mtg. I have comments to integrate before sending to www-tag.
IJ: Big things won't happen for arch doc before end of June. I can have a good draft for ftf meeting.
[DanC]
yeah... it's a real bummer for us to have these marathon meetings only to have the editor say "hold that thought for 2 weeks"
[Ian]
---
NW: Push story in 3.4.1 to earlier in 3.4. Move up "All important resources SHOULD be idnetified by a URI" since not about representations.
TB: Yes, move to the top.
IJ: Ok, I'll move that note higher up in the doc.
TB: Put it in 3. (before 3.1). Under 3.4.2, put in the example of the bank account. When you say "Yes, charge my credit card for the ticket to Oaxaca" to expand on scenario in section 1.
IJ: I can steal some text from finding to flesh out 3.4.2 a bit; it's barren as it stands.
TB: Leave 3.4.3 with reference to deep linking finding.
NW: Move 3.4.3 up (talk about identification without access before talking about access)
[Ok]
[3.4.4 Servicing a URI]
TB: Please include the word "persistence" in the title of 3.4.4
NW: Yes. I'd like a different title for 3.4.4
[TBray]
"predictability"? "consistency"?
[Ian]
Some suggested alternative titles for section 3.4.4:
  1. Resource persistence and representation consistency
  2. Consistency
NW: I think should be moved to 3.5 instead of 3.4.x
TB: Another case is use of namespace name for different things over time. Leave moby dick example unless you can cover all the bases with expanded scenario.
[Some agreement to move 3.4.4 to 3.5]
RF: Add 3.6 - future directions.
  1. IRIs
  2. Things that are not administrative hierarchies (e.g., freenet, edonkey2000)
  3. Dereferenceable URNs; see DDDS work.
[DanC]
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
-- http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt
[Ian]
TB: Anything in 3.4.4 (or three generally) that at the current time clashes with either TBL or RF view of what a resource is?
RF: This text mixes up resource metadata and representation of the resource. Odd to see consistency of representations mixed with consistency of metadata; perhaps create a subsection for each. Consistency of both is a good thing.
TBL: Fine by me to say that 2 URIs can identify the same resource.
[Chris]
how do you know - only by dereferencing and comparing the resources?
[Ian]
[Schedule]

TB: If people are basically ok with section 4, we are within spitting distance of a coherent publishable document. How do we get to last call?
DO: Question of scope of arch doc: Whether to include more on sem web and web services or not.

[TBray]
what TimBL said
[Ian]
TBL: I think we should go ahead with last call if we are happy with what we have.
[DanC]
I think there's an attainable WD target in the near term. maybe that's so obvious that it's boring.
[Chris]
but still worth stating
[Ian]
TBL: We have got a subset. I think that DO is right that our scope includes Web Services, etc., but I don't think we save time by not publishing a last call.
TB: I think that we need to take this through last call to get people to read seriously and have a stake in the ground. I can't imagine that it would be good to leave it in WD status..
[Zakim]
Chris, you wanted to talk about loaded questions
[Ian]
CL: I agree we should take it to first last call. Might take a subset of the doc to Rec and work on rest separately.
DO: Why did we ask the AC what they want?
CL: Communication (what questions we face, tradeoffs we are considering making, awareness of our work)
DO: Some people brought up the issue of "last call". Have we closed all of our issues?
PC: I agree with DO; I think that there are a fair number of AC reps who want the arch doc to talk about web services and semantic web. If we decide that we have to put that info in the future directions sections, then I expect we'll get a bunch of comments.We'd need to indicate limits of doc in status section. Process Doc is a leading example of how to handle an evolving document (publish so often and cut off issues list)
[DanC]
I won't be party to any decision to go to "first last call". if "last call" is treated like crying wolf, it'll further lose value.
[Ian]
PC: the Adv. Board batches the effort. I'd like to go forward with a first last call, but bring to the AC's attention that we haven't gotten as far as some AC reps might like.
[Zakim]
DanC, you wanted to noodle on last call before... what? before we ask the AC who said they're not interested in a document of this scope? and to say "I won't be party to any decision to go to "first last call". if "last call" is treated like crying wolf, it'll further lose value."
[Ian]
DC: I think we have clearly conflicting advice. I'd like to declare victory at an early opportunity. If we go to last call, we should be ready to go to the next step. Not sure whether next step should be CR or PR. We might be promising to "hold still" on the backward-looking part of the document.
[Chris]
first last call means we have no guarantee that we get to cr; clearly if all review is positive then we go to cr, but lots of review often means lots of feedback, often for the first time
[Ian]
DC: I would have hoped the AC would say -publish early publish often; but that's not the advice we got.
RF: The section of interactions will have (even in skeletal form), something on http, web services, and sem web. How those categories impact the notion of interaction. I am on hook to finish this section for next week.
TBL: I don't see how sem web part of interaction...
TB: Most of current arch doc result of 10 years experience.
[DanC]
quite.
[Ian]
TB: Not getting around the fact that as soon as we move to sem web and web services, our experience will be very different. Will be qualitatively different from what we have.
[DanC]
"quite" re semweb/web-svcs being newer
[Ian]
TB: We should get to a point where we think we've gotten to a point where we are happy with what we've written about how the thing works today; we owe that to the community.
[DanC]
where was tbray during the AC meeting? 1/2 ;-)
[Ian]
TBL: The Process Doc doesn't address this situation - half-completed document clashes with dfn of last call. One possibility is to say, e.g., "last call on arch doc, part I. "We'll be working on parts I and II, but think last call on part I reasonable.
[Zakim]
Chris, you wanted to agree about the 'from experience' part but we don't have all that down yet
[Ian]
CL: Line through old / new stuff not that clear. People have been doing some aspects of web services for a long time. There is stuff that's not in the arch doc where we have experience but we haven't had time to work on it.
[DanC]
(btw... I'm hoping the I18N WG splits the charmod spec likewise; did we ask them to do that? have we gotten a reply?)
[Ian]
PC: Some TB text might be good rationale to take back to AC; why we are taking to last call now.
[Chris]
we did ask them and they did not reply
actually I believe they said no unoffiially
[Ian]
PC: There are folks in Web Services area who want TAG's help in that area; would like to get us involved in that area sooner rather than later.
[Chris]
so we need to fget an official answer
[Ian]
PC: We need to respond to AC's signal
SW: We have a WSARCH WG; I am not conscious of any issues that have been fed to us from that WG.
PC: We have had direct requests from other wgs in that activity (e.g., wsdl).
IJ: Issue 37, not to mention SOAP/GET
PC: If the TAG decides that it wants to go to LC, has a mandate to respond to the AC, set expectations about material we will cover and how.
[Zakim]
tim_mit, you wanted to say that there is a lot of arch work already done in sw area which could be pointed to.
[Ian]
TBL: Owl/RDF Core groups have done a bunch of architectural stuff.
DO: I observe that we've had a couple of issues with web services groups; if we reacted quickly to questions from these groups we'd get even more questions.

[DO mentions target resource attribute]

DO: People that are in these communities aren't looking for TAG help on current issues in this area; we haven't expressed too much interest of being in those areas.
IJ to TBL: Send me data on arch info related to sem web if you'd like included in references section.
[Returning to schedule issue]
TB: I think that going to LC/CR/PR is good on a document. If we don't do that sometime, then we won't benefit. If we have consensus that we would lke to get to LC sooner rather than later, then we should tell the AC and see if they are ok with that.
[Ian]
Straw poll - July last call on arch doc part I?
  1. Yes: TB, DC, NW, CL, IJ, TBL, SW, PC, DO
  2. Abstain: RF
[Roy]
I will be travelling almost all of June 19-July 24
[Ian]
DC: Anyone want to take an action to reset expections within the AC?
[DaveO]
I'll concur. I think we wasted time asking the AC.
[Ian]
DO: If we really wanted to go to last call end of July, we should have told the AC that. We should have set clearer expectations at the AC meeting; explained to them the down sides. I think the question we asked them missed the mark; we didn't get back information that we found useful.
TB: That may be true, but until we went through the call today, I don't think we knew.
[DanC]
yes, I think that's life... hindsight is 20-20.
[Ian]
SW: Folks, please make progress on your action items before our next teleconf.
Action DO/PC: Send draft of AC announcement to tag@w3.org.

3. Not addressed

3.1 Findings

See also: findings.

Next steps for draft findings:

3.2 New issues?

3.3 Issues that have associated action items

4. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/10 15:28:38 $