W3C | TAG | Previous: 4 Dec teleconf | Next: 5 Jan 2004

Minutes of 15 December 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative (15min)

  1. Roll call: PC, SW (Chair), DC, DO, TBL, RF, NW, TB, IJ (Scribe). Regrets: CL
  2. Accepted the minutes of the 1 Dec teleconf.
  3. Accepted the minutes of the 4 Dec teleconf.
  4. Accepted the TAG monthly summary with addition of text on XML 2003.
  5. Accepted this agenda
  6. Next meeting: 5 Jan 2004. Regrets: RF

1.1 Feedback from XML 2003 Town Hall?

[Ian]

TBray: I was satisfied with some of the commentary from the floor to improve the document.
DC: There may be confusion between Web arch and Web Services arch
[DanC]
in fact, there was
[Ian]
TBray: I think XML 2003 not our natural constituency; thinly attended town hall.
DC: Also evening...

1.2 Last Call Update

Negotiations with WGs for last call:

  1. SW/I18N: SW sent. Reply pending from I18N.
  2. Schema/PC: PC sent. MSM has confirmed for Schema WG.
  3. SVG/CL: CL sent. CL has confirmed for SVG WG.
  4. HTML/IJ: IJ sent. SP has confirmed for HTML WG.
  5. XML Core/NW: NW has confirmed.
  6. Webont WG/SW: Jim Hendler has confirmed.
  7. Voice/SW: SW/IJ think Voice WG will be doing a review.
  8. RDF Core/SW: Brian McBride will seek commitment from RDF Core WG

1.3 Patent Policy

Charter needs revision; suggest sending for AC review once policy operational.

[Ian]

IJ: We are implementing new patent policy; likely to modify TAG charter.
[Discussion of patent policy transition]
[Zakim]
TBray, you wanted to say yes, we need to be 100% clear on this

1.4 Video meeting in Feb 2003

  1. Action SW/PC 2003/12/15: Propose TAG distributed videolink meeting around 9 Feb 2004.
  2. Other constraints:
    1. NW: 2 February problematic.
    2. TB: Likely regrets for 9 Feb.
    3. TAG election results expected by 30 Jan 2004.

1.5 Technical Plenary

  1. TP F2F Observers Yes/No, with/without prior agreement, Public/Member only?
  2. Continued action SW 2003/11/15: Take to tech plenary committee the TAG's proposal.
  3. TBL will not be traveling to France for the meeting.

[Ian]

SW: Should we invite observers to the TAG's ftf meeting 2 Mar 2004?
DC: If we don't ask for prior agreement from Chair, I can almost guarantee some people will wander in.
TBray: I'm ok with observers.
PC: I'm against observers. We do our technical discussion in public; why do we have to have our ftf discussions in public?
[DanC]
I prefer "yes, with prior arrangement" (but I said that in email)
[Ian]
TBL: Not thrilled with the idea of a televised private meeting; people need to realize we are not meeting for them. There is also a risk that people take away partial/incorrect answers based on our discussion.
[TBray]
Not passionate about this one, could go either way
[Ian]
DC: I think people can attend if they ask the chair in advance and have a good reason to be there.
[tim-mit]
+1 for prior arrangement only
[Ian]
IJ: Past messages make clear that "observer <> short-term participant"
SW Proposes to revise his answer to "No observers"
DO: I think I would object.
TBray: I think I would too.
SW Proposes to revise his answer to "Observers ok with prior arrangemetn with the Chair."
So RESOLVED: SW will revise answer to tech plenary committee as proposed : "observers ok with prior arrangement of the Chair"

2. Technical (75min)

  1. Review of qnameAsId-18 finding
  2. Review of contentTypeOverride-24 finding
  3. Review of XMLP WG request regarding uriMediaType-9

2.1 Review of qnameAsId-18 finding

See also TAG findings. Draft finding from NW on QNames on qnames

[Ian]

NW: I have not been able to make changes desired by DO in time for this meeting. I propose to do those revisions by our 5 Jan 2004 teleconf.
DC: Do you expect to talk about canonicalization?
NW: Yes. Also, I think 3 Nov draft is the latest draft to date.

2.2 Review of contentTypeOverride-24 finding

10 Dec draft of "Client handling of MIME headers"

[Ian]

[IJ reviews]
Announcement, Comments from SW
SW: Diff between resource provider and resource owner? I think leads to confusion about resource v. representation.
IJ: "Resource provider" is from RF; I'd like to hear from him.
[DanC]
in webarch we call it the "owner" of the resource, no?
[Ian]
RF: I was referring by "resource provider" to people, not mechanism.
IJ: I recognize as a bug in finding if person and origin server confused.
[Zakim]
tim-mit, you wanted to ask whether we can use 'owner"
[Ian]
TBray: "Ownership" is defined in arch doc.
TBL: Then let's use that in the finding.
[DanC]
hear hear
[Ian]
RF: Sure.
[Stuart]
+1
[DanC]
cf http://www.w3.org/TR/webarch/#uri-ownership
[Ian]
SW: I propose that we discuss this finding again at our 5 Jan meeting.
DC: I'd rather have two advocates
Action TB, SW: Review finding by 5 Jan 2004 teleconference, and work with IJ.

2.3 Review of XMLP WG request regarding uriMediaType-9

XMLP WG request for revision of uriMediaType-9 issue and related finding

[Ian]

DO: XLMP WG talking about encoding media type information in XML. The finding is a bit out of date (8 Apr 2003) and IANA has made some changes since then. From DO email: "We seem to have 3 major options available for identifying media types in XML: 1) IANA media type tokens, ie xsi:mediaType="image/jpeg". 2) HTTP URIs, ie xsi:mediaType="http://www.iana.org/assignments/media-types/image/jpeg" 3) URN URIs, ie xsi:mediaType="urn:ietf:param:contentType:image:jpeg""
[TBray]
URN URIs, ie xsi:mediaType="urn:ietf:param:contentType:image:jpeg
[Ian]
DO: Problem with HTTP URIs was that not available for all media types.
[TBray]
e.g. http://www.iana.org/assignments/media-types/image/jpeg is not available
[Ian]
DO: I think the finding needs to be updated.
See CL's action item on issue 9.
[Zakim]
DanC, you wanted to clarify: IANA has provided http URIs for a while; but they don't promise not to 404 them at a moment's notice
[Ian]
http://lists.w3.org/Archives/Member/tag/2003Oct/0082.html
DC: I have been trying to extract promise of persistence from relevant folks.
http://lists.w3.org/Archives/Member/tag/2003Oct/0079.html
[Stuart]
http://www.w3.org/2001/tag/2002/01-uriMediaType-9
[DanC]
ah... found http://www.w3.org/2001/tag/2002/01-uriMediaType-9.html Revised 27 May 2002
[Ian]
IJ: I recall CL talking about missing HTTP URIs for media types.[Not sure]
[DanC]
CL's action is still outstanding, per http://www.w3.org/2001/tag/issues.html#uriMediaType-9
[Ian]
DO: I'd like for the TAG to address this before arch doc 1.0
DC: What is your suggestion?
DO: Revise finding, making trade-offs clear. Feb 2004 seems ok as time frame. I'd like the finding to say "Use HTTP URIs as provided by IANA." Or something as simple.
DC: Note that IANA answers with 200 ok, but doesn't commit to doing so forever.
RF: I suggest that DO respond to the WG that they use the media type and nothing but the media type.
[DanC]
next IETF/W3C telcon is scheduled for 6 Feb 2004
[TBray]
+1 to Roy
[Ian]
DO: Validation may be simpler if there is one, not two way to specify media type.
RF: No software that I am aware of uses a URI; they all use the short string.
[Roy]
/me uses a URI to define the media type
[Ian]
TBL: I agree with TB's initial analysis. I think that the finding can say what *ought* to happen (use HTTP URIs) and then there's the question of what to do in practice. I suggest that the finding suggest what ought to happen. And we continue discussions with the IANA folks. And that we find a solution in the short term for the WG. We can build a registry in W3C space for mime types. We've had a list of mime types before.
[TBray]
Per Web Architecture, it would be ideal to refer to Internet Media Types as Web Resources, i.e. using URIs. If however the organization that logically owns these resources is not interested in publishing URIs for them, the choices are to use the Internet Media Types they publish, or cook up our own URI-addrssable registry
[Ian]
TBL: We can note that these URIs will not be persistent beyond, say 1 year, and we will maintain the URIs for that duration.
[DanC]
fyi, Martin built a list of MIME types that sorta come from W3C recently. http://www.w3.org/2002/06/registering-mediatype.html#Status
(my list was URI schemes)
[Ian]
TBL summarizing:
  1. Tell WG what to do right now
  2. Negotiate with IANA; propose W3C manages a registry that IANA can clone.
  3. Put the principles behind this in the finding.
SW: I agree that finding should say that, in the absence of URIs, to use content type short strings as is.
DC: No thanks (to SW's suggestion).
TBray: The idea of a semi-authoritative registry doesn't strike me as a good idea. RDDL has this problem, too.
[DanC]
people can figure out to use names like "text/plain" on their own; there's no value in the TAG endorsing that practice.
[Zakim]
TBray, you wanted to blanch at the idea of an interim semi-authoritative registry
[Ian]
TB: Will be important to have a URI for these things if there is to be RDDL mapping to RDF.
[DanC]
well, RDF can deal with "text/plain" strings just fine.
[tim-mit]
But that does not allow any old person to invent a personalmedia type.
[Ian]
DO: Two issues if W3C provides registry: (1) dereferencable or not? (2) or just URI space not used for any other resource types.
[Roy]
suggestion: 1) Tell working group to use media-type with some simple algorithm for parameter ordering (lexical); 2) write up the algorithm as instruction to IANA (an RFC); 3) point out to WGs that the media type is simply a URI relative to the IANA registry base URI.
[TBray]
Yes, but I want to say that with respect to http://example.com/ns/x, that http://example.com/schemas/x.xsd has a nature of <insert namespace name for XML Schema>
[Ian]
RF: E.g. of algorithm: List the parameters in lexical/alphabetical order.
[TBray]
but, if I want to provide a related resource that's a CSS stylesheet, how do I identify its nature?
[Ian]
RF: Point out to the WGs that there's a relative URI into a registry, wherever the registry is. That way you get both - media types and URIs at the same time. I suggest we update the finding to say this. To get IANA attention, write an RFC.
DC: Been there /done that; see Internet Draft co-authored with Mark Baker.
RF: When the RFC is published, IANA will follow it There mandate is to follow the instructions of the IETF...
DC:...except when the instructions conflict. Mark Baker and I are to ask for last call of our Internet Draft
DC to DO: Do you want to attend the W3C/IETF meeting on 6 Feb 2004?
DO: If I'm available; sure.
Action DC: Invite DO to IETF/W3C for 6 Feb 2004.
[DanC]
... noting varous risks
[Ian]
SW: Any finding updates expected?
DO: I am hearing "If you need to make a decision right now; use media type strings. We are negotiating the use of URIs for the IANA registry." We'd like authoritative URIs, but we're not there yet.
TBray: I heard RF suggest that we start minting URIs for the IANA...
RF: The media type is structured like a URI; if you start out using the media type alone, but add an ordering mechanism for the parameters (which are rarely used), the name that you use is a URI. It's just relative.
[Zakim]
DanC, you wanted to say if you need a decision right now, TAG isn't finished with the issue, so go ahead and make your own decision
[Ian]
DC: I haven't heard any suggested changes to finding that i consider an improvement.
TBray: I hear RF saying that we take proactive action.
DC: We are doing that; those negotiations are not yet done. I'm against some short-term action by the TAG; people can do what they want, but not with the TAG's blessing.
SW: I think we have already decided this issue, and the answer is in the finding.
TBL: I hear people saying "These media type strings are relative URIs w.r.t. the IANA registry....we need to do some things to make this happen in practice..." But I don't think what we need to do with IANA has to be our first action. In fact, IANA may respond to the community if there is consensus there.
DO: Is there any connection between DC/MB's internet draft and RF's algorithm?
RF: My suggestion for the WG is to just use the media types today.
TBL: Can we say: If you want to look ahead, treat as a relative URI reference. But we can't tell you the base URI today. I think the answer to the WG should be:
  1. Identify media types with URIs (of course)
  2. But we can't tell you yet the base of the URI
  3. We can't make guarantees about persistence/dereferenceability today.
[Roy]
agrees with TBL
[Ian]
DC: That's not the answer I want to give today.
TBL: Why does the WG need to make any changes to its spec?
[tim-mit]
DO: What if the base changes?
[Ian]
DC: I expect the TAG to resolve the issue in good course; I don't want to endorse anything until we resolve the issue. I am waiting for the IANA negotiations to finish first.
[DanC]
"The TAG would prefer that dereferencable http: scheme URIs be assigned under the authority of the body that maintains the Internet media type registry."
[Ian]
DO: I think I can wait a few weeks before I next talk to XMLP WG about this.
TBL: I'm concerned about the idea of trying to convince IANA before we implement this on our site. The picture that RF painted was that, if you write up an RFC, and you have some community behind you, then IANA will go ahead and do it.: I've not seen the IANA agree "in principle"
SW: I request that people review the current finding and suggest concrete revisions.

2.4 Other

The TAG did not address the following

2.5 Issues

Issues list

Issues that are open and that we expect to close by the end of last call:

2.6 Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/12/16 02:01:23 $