W3C | TAG | Previous: 1 Jul | Next: 15 July | IRC log

Minutes of 8 July 2002 TAG teleconference

Nearby: issues list · www-tag archive

1. Administrative

  1. Roll call. TB, SW (Chair), DC, NW, IJ, CL, DO, PC. Regrets: TBL, RF
  2. Accepted this agenda.
  3. Next meeting: 15 July. Regrets: CL
  4. Accepted 1 July minutes
  5. Accepted summary of TAG activity in June
  6. Confirmed status of completed actions
  7. Quorum rules
  8. Prioritization of issues

1.2 Completed actions

  1. Action IJ: Publish architecture document, asking in particular for input on issue httpRange-14. Done.
  2. Action SW: Respond to XMLP WG on behalf of TAG. Done.
  3. Action IJ: Integrate/combine one-page summaries (into architecture document)

1.3 Quorum rules for the TAG

The TAG charter does not include quorum requirements. The TAG agreed at this meeting not to institute quorum requirements, to use common sense when making decisions when few people are at a meeting.

1.4 Prioritzation of issues

The TAG began to discuss prioritization of its issues, when the topic shifted to expectations of a timeline for publishing the draft Architecture Document as a W3C Working Draft. There was general agreement that the TAG should do this as soon as possible (and certainly before resolving all the issues on its issues list). The TAG set a goal of further fleshing out this document and publishing a first Working Draft by mid-August, with a drop-dead date of 30 August.

Action IJ: Find out whether the W3C Comm Team expects to have a publishing moratorium in August.

2. Technical

See also: findings.

2.1 Architecture document

  1. ACTION TBL 2002/05/05: Negotiate more of IJ time for arch doc
  2. ACTION RF 2002/06/24: Write a paragraph on technical and political aspects of URIs and URI References.

Review of some portions of the 1 July architecture document. The following notes have been reordered somewhat to map to arch doc sections.

Section 1.1 URI schemes

[Ian]

TB: What do we do to make 1.1 work? Some of the things in the list under schemes are duplicates. Bullet one would apply to all URIs if we took RF's wording. Are other people happy with 1.1?
DC: I think the list is interesting, but I'm not satisfied that it works.
SW: I'd like to mention 1.1 scheme-agnostic. What about a table of schemes and properties? Section 1.1.1 is about persistence, also a property in the table. Should we have prose for each of the properties we identified?
IJ: I think scheme properties are a useful entry point for other issues we encounter later on.
Parallel actions TB, DC: Propose text for section 1.1.

Section 1.1.2 Central registries

[Ian]

CL: I have a problem with 1.1.2 (central registries). Centralized registries of formatting properties is also useful. As is the W3C /TR page.
DC: /TR is not a centralized registry. It's not necessary for every party who does Web business to consult /TR to continue in life. /TR is not central to the operation of the Web.
CL: So what about browsers making up HTML?
TB: There's a qualitative difference between DNS and /TR.
DC: There is a central registry for MIME types.
CL: You don't have to look up IANA registry each time as a user.
TB: But browser developer needs to have hard-coded.
CL: Is the definition "You looked up once in one place" or "You have to look up each time." Having single points of failure is something else.
DC: As written, the text doesn't make the case why central registries are bad. There are at least two: URI schemes, list of MIME types. I would still claim these are exceptions.
CL: Is 1.1.2 for the whole document or just 1.1?
DC: I think in context. We like anyone to be able to make up names. But there are exceptions (e.g., DNS).
CL: Then we should say that 1.1.2 only applies to naming.
DC: But naming is the only place where central registries would come up.
CL: Why is 1.4 part of section 1, not formats?
SW: Part of a URI reference.
DC: Good point, though. Maybe it could move to 2 (with link to it from chapter 1)
TB: On central registries - I think we are telling spec writers "Don't assume a central registry at W3C must be required in order for your spec to work." Given that principle, DNS is arguably unfortunate, but we're stuck with it. I think DNS different from getting a MIME type definition (since everyone does this all the time). I think that the intent of 1.1.2 is fine. I support the principle as stated and I think it applies to issues outside of URIs. Applies to protocols and formats as well.

Section 1.1.1 Social expectations for URI persistence

SW: Just before 1.1.2, we do some URN-bashing. What should we say about IETF efforts to make URNs dereferenceable?

DC: This came up under Media type rubrique. I hope this is still on todo list. Michael Mealing has made points about IETF decisions regarding single points of failure. I was not aware of that decision. I would like to track down how decisions are made in that area. Two points
  1. TBL was out of line saying on the list that URNs are not dereferenceable.
    TB: But in fact URNs are *not* dereferenceable.
  2. Michael and Tim Bray seem to agree (on the list) to the fact that we should use dereferenceable URIs, whatever scheme.

TB: I think we agreed that dereferenceability is a useful characteristic and that it's a good thing to call that out.
DC: My issue with URNs is that they just recreate HTTP. HTTP has administrative hierarchy, and you get to do whatever you want in your HTTP space. As far as I can tell, URN technology doesn't change that - login, then search, then one TCP transaction. There should be an arch principle on not reinventing the wheel. Process question - how can TAG and IETF parties communicate better?
TB: Principle - Persistence is a matter of policy, not technology. Nothing in HTTP prevents you from managing your space well. Perhaps we should just drop URN reference unless we take up DC's point that harmful to reinvent wheel.
NW: I think we'd be hard pressed to argue that URN is a new scheme.
TB: Please add a boxed principle: "Persistence is a key characteristice in URI design."
DC: A comment I made on the phone with IJ - a lot comes down to "economics". Value to having name agreed by people. If it changes, then the value goes down.
TB: We say "there are strong social expectations..."
DC: The document doesn't say what the expectations are.

DC: Two decisions were made in the IETF pertaining to URNs:
  1. DDNS documents proposed standard; I tracked down
  2. Decision not to use HTTP URIs to name protocols. I don't know where that decision was made.

Action DC: Ask Michael Mealing when IETF decided not to use HTTP URis to name protocols.

Section 2: Formats

[Ian]
CL: Not sure what I would write in Section 2... Section 2 is the big bleeding piece for me.
TB: I think the meat is in section 2. All it needs is to invest time to wrap text around each issue. Seems mostly editorial. You could build short sections for 2, as done for current 1.4.1. I think we have consensus on format properties as well.
CL: You can put a list of alternatives around issues as well.

Action CL: Write up some text for section 2. Deadline 30 July.

Additional principles

[Ian]

DC: One principle I've heard about formats is to separate presentation from structure is an arch principle as well.

2.2 Internet Media Type registration, consistency of use

  1. ACTION DC: research the bug in the svg diagram. Done.

    TB, CL: Remove. PC: Neutral.

    DC: I'm happy to do without TBL since Martin said I18N folks would do something with it if TAG doesn't.

  2. ACTION NW 2002/06/24: Produce PNG version of image as well. Done.

Resolved: Remove diagram from finding.

[TBray]

The finding is not done due to issue RFC3023Charset-21.
[Ian]
Current text:
"If so, the IETF registration forms MUST be part of the language specification, and SHOULD be part of the specification starting at Candidate Recommendation status (or Last Call if the Working Group plans to have sufficient implementation experience to bypass Candidate Recommendation). "
DC: IETF area directors didn't say you had to have the mime type in registry before you could use it.
[DaveO]
hmm.. seeming less and less like an architectural principle and more like w3c process issue.
[Ian]
IJ: The text must be in spec, but isn't required to be registered.
DC: Area directors said "Don't want to put in the registry until it goes to Rec." They prefer to just have internet draft published every 6 months. They would rather your type not be in registry but not in internet draft index.
CL: What can we point to when people tell us we are doing it wrong?
TB: I agree with DO's point that this is a process issue. Let's rewrite finding to say that registration process must proceed in parallel with w3c process, and documents must be readily available from w3c specs.
DC: Water down more: Registration information is relevant and needs to be reviewed along with everything else in your spec.
IJ: Please note current best practice as we understand it.
TB: if we write a strong arch principle saying "You have to get this work done" then that is enough for the Director to stand on.
PC: I think we need a cookbook for chairs on what to do.
DO: I'd rather us spend more time on arch principles and our issues list.
[TBray]
Particularly given that the TAG has substantial consensus... it's irritating that we have to keep investing time on this. If we want a cookbook, how do we get it?
[Ian]
DC: I agree that this is process, but who do we hand this to?
PC: Our finding should say "here lie alligators" if uncertain process.

Action PC: Propose alternative wording for finding.

Action CL: Send copy of information sent to tag regarding RFC3023 to www-tag.

2.3 Consistency of formatting property names, values, and semantics

NW: I see Håkon's reply only now (due to email problem).
CL: CSS WG wanted previous good behavior mentioned in the finding.
DC: HWL's message suggested a central regisry. Are we saying "no thanks" to that suggestion?
TB: Our finding is correct. Hakon suggested writing down a process. I don't think this changes the finding.
CL: In other words, we don't care how you get it right as long as you do?
DC: Works for me.
NW: I will make another stab that mentions good behavior and presumably we can call it done at that point.

2.4 Are we done with whenToUseGet-7?

ACTION DC 2002/06/10: Send note to WSA WG expressing concern about normative binding for GET. Done.
SW: Are we done with issue whenToUseGet-7?
DC: Not to my satisfaction. I haven't seen message to or reply from WSA WG.

DO: In my court. I've had discussions with various people. I'm still working on what possibly we should try to say to them. Certainly dealing with SOAP 1.2 is an issue before WSDL. I think we should go to them with something more refined.

TB: I think that the news is good, however, notably on WSDL front. It's now on their radar.: My understanding is that they will build machinery to handle it.
  1. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?

2.5 augmentedInfoset-22

1. ACTION DC 2002/06/17: Talk to XML Schema WG about PSVI. Report to tag, who expects to decide whether to add as an issue next week. Done (email to Schema WG).
DC: I don't think we should close until we've heard back from them.
NW: Schema WG tried to consider DC message at meeting 2 weeks ago. I don't think it was clear what we were asking them.
DC: They need to tell me how they are confused. Please mark as open Tim's action regarding communication with IETF about media type names as URIs (issue URIMediaType-9). See message from DanC.

2.6 Postponed

  1. Qnames as identifiers
    1. Action NW 2002/06/24: Follow up on Rick Jelliffe comments/proposal.
  2. httpRange-14: Need to make progress here to advance in Arch Document.
  3. Status of URIEquivalence-15. Relation to Character Model of the Web (chapter 4)? See text from TimBL on URI canonicalization and email from Martin in particular.

New issues?

  1. Bad practice: Overriding HTTP content-type with a URI reference.See email from TBL.
  2. "Deep linking illegal" bad practice? See email from Tim Bray.
Ian Jacobs, for TimBL
Last modified: $Date: 2003/12/17 18:51:15 $