W3C home > Mailing lists > Public > www-tag@w3.org > December 2003

[Minutes] 15 Dec 2003 TAG teleconf (uriMediaType-9, contentTypeOverride-24, admin)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 15 Dec 2003 18:40:33 -0500
To: www-tag@w3.org
Message-Id: <1071531632.10222.250.camel@seabright>

The minutes of the 15 Dec 2003 TAG teleconf are
available as HTML [1] and as text below.

  _ Ian

[1] http://www.w3.org/2003/12/15-tag-summary.html

                Minutes of 15 December 2003 TAG teleconference

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 [9]1 Dec teleconf.
    3. Accepted the minutes of the [10]4 Dec teleconf.
    4. Accepted the [11]TAG monthly summary with addition of text on XML
    5. Accepted this [12]agenda
    6. Next meeting: 5 Jan 2004

      [9] http://www.w3.org/2003/12/01-tag-summary.html
     [10] http://www.w3.org/2003/12/04-tag-summary.html
     [11] http://lists.w3.org/Archives/Member/tag/2003Dec/0064.html
     [12] http://www.w3.org/2003/12/15-tag.html

  1.1 Feedback from XML 2003 Town Hall?


          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

          in fact, there was

          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

   [13]Charter needs revision; suggest sending for AC review once policy

     [13] http://www.w3.org/2001/07/19-tag


          IJ: We are implementing new patent policy; likely to modify TAG
          [Discussion of patent policy transition]

          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.


          SW: Should we invite observers to the TAG's ftf meeting 2 Mar
          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?

          I prefer "yes, with prior arrangement" (but I said that in

          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.

          Not passionate about this one, could go either way

          DC: I think people can attend if they ask the chair in advance
          and have a good reason to be there.

          +1 for prior arrangement only

          IJ: Past messages make clear that "observer <> short-term
          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. [14]Review of qnameAsId-18 finding
    2. [15]Review of contentTypeOverride-24 finding
    3. [16]Review of XMLP WG request regarding uriMediaType-9

  2.1 Review of qnameAsId-18 finding

   See also [17]TAG findings. [18]Draft finding from NW on QNames on

     [17] http://www.w3.org/2001/tag/findings
     [18] http://www.w3.org/2001/tag/doc/qnameids-2003-11-03


          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

   [19]10 Dec draft of "Client handling of MIME headers"

     [19] http://www.w3.org/2001/tag/doc/mime-respect.html


          [IJ reviews]
          [20]Announcement, [21]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.

     [20] http://lists.w3.org/Archives/Public/www-tag/2003Dec/0174.html
     [21] http://lists.w3.org/Archives/Public/www-tag/2003Dec/0189.html

          in webarch we call it the "owner" of the resource, no?

          RF: I was referring by "resource provider" to people, not
          IJ: I recognize as a bug in finding if person and origin server

          tim-mit, you wanted to ask whether we can use 'owner"

          TBray: "Ownership" is defined in arch doc.
          TBL: Then let's use that in the finding.

          hear hear

          RF: Sure.


          cf [22]http://www.w3.org/TR/webarch/#uri-ownership

     [22] http://www.w3.org/TR/webarch/#uri-ownership

          SW: I propose that we discuss this finding again at our 5 Jan
          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

   [23]XMLP WG request for revision of uriMediaType-9 issue and related

     [23] http://lists.w3.org/Archives/Member/tag/2003Dec/0062.html


          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
          image/jpeg" 3) URN URIs, ie

     [24] http://www.iana.org/assignments/media-types/image/jpeg

          URN URIs, ie

          DO: Problem with HTTP URIs was that not available for all media

          e.g. [25]http://www.iana.org/assignments/media-types/image/jpeg
          is not available

     [25] http://www.iana.org/assignments/media-types/image/jpeg

          DO: I think the finding needs to be updated.
          See CL's action item on issue 9.

          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

          DC: I have been trying to extract promise of persistence from
          relevant folks.

     [26] http://lists.w3.org/Archives/Member/tag/2003Oct/0082.html
     [27] http://lists.w3.org/Archives/Member/tag/2003Oct/0079.html


     [28] http://www.w3.org/2001/tag/2002/01-uriMediaType-9

          ah... found
          Revised 27 May 2002

     [29] http://www.w3.org/2001/tag/2002/01-uriMediaType-9.html

          IJ: I recall CL talking about missing HTTP URIs for media
          types.[Not sure]

          CL's action is still outstanding, per

     [30] http://www.w3.org/2001/tag/issues.html#uriMediaType-9

          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.

          next IETF/W3C telcon is scheduled for 6 Feb 2004

          +1 to Roy

          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.

          /me uses a URI to define the media type

          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.

          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

          TBL: We can note that these URIs will not be persistent beyond,
          say 1 year, and we will maintain the URIs for that duration.

          fyi, Martin built a list of MIME types that sorta come from W3C
          (my list was URI schemes)

     [31] http://www.w3.org/2002/06/registering-mediatype.html#Status

          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.

          people can figure out to use names like "text/plain" on their
          own; there's no value in the TAG endorsing that practice.

          TBray, you wanted to blanch at the idea of an interim
          semi-authoritative registry

          TB: Will be important to have a URI for these things if there
          is to be RDDL mapping to RDF.

          well, RDF can deal with "text/plain" strings just fine.

          But that does not allow any old person to invent a
          personalmedia type.

          DO: Two issues if W3C provides registry: (1) dereferencable or
          not? (2) or just URI space not used for any other resource

          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.

          Yes, but I want to say that with respect to
          [32]http://example.com/ns/x, that
          [33]http://example.com/schemas/x.xsd has a nature of <insert
          namespace name for XML Schema>

     [32] http://example.com/ns/x,
     [33] http://example.com/schemas/x.xsd

          RF: E.g. of algorithm: List the parameters in
          lexical/alphabetical order.

          but, if I want to provide a related resource that's a CSS
          stylesheet, how do I identify its nature?

          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 [34]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
          DO: If I'm available; sure.
          Action DC: Invite DO to IETF/W3C for 6 Feb 2004.

     [34] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt

          ... noting varous risks

          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
          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.

          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

          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
          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
          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

          agrees with TBL

          DC: That's not the answer I want to give today.
          TBL: Why does the WG need to make any changes to its spec?

          DO: What if the base changes?

          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.

          "The TAG would prefer that dereferencable http: scheme URIs be
          assigned under the authority of the body that maintains the
          Internet media type registry."

          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
     * [35]contentPresentation-26: Draft finding: [36]Separation of
       semantic and presentational markup, to the extent possible, is
       architecturally sound
     * [37]metadataInURI-31
     * [38]siteData-36
     * [39]abstractComponentRefs-37
       Completed action IJ 2003/11/03: Publish DO's latest draft in
       finding format ([40]Done)

     [35] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
     [36] http://www.w3.org/2001/tag/doc/contentPresentation-26-20030630.html
     [37] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
     [38] http://www.w3.org/2001/tag/issues.html#siteData-36
     [39] http://www.w3.org/2001/tag/issues.html#abstractComponentRefs-37
     [40] http://lists.w3.org/Archives/Public/www-tag/2003Nov/0008.html

  2.5 Issues

   [41]Issues list

     [41] http://www.w3.org/2001/tag/issues.html

   Issues that are open and that we expect to close by the end of last
     * [42]rdfmsQnameUriMapping-6
     * [43]whenToUseGet-7
     * [44]URIEquivalence-15
     * [45]errorHandling-20
     * [46]contentTypeOverride-24

     [42] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#rdfmsQnameUriMapping-6
     [43] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#whenToUseGet-7
     [44] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#URIEquivalence-15
     [45] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#errorHandling-20
     [46] http://www.w3.org/2001/tag/issues.html?view=normal&closed=1#contentTypeOverride-24

  2.6 Other action items

     * Action RF 2003/10/08: Explain "identifies" in RFC 2396.
     * Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly
       on how to raise awareness of this point (which is in CUAP).
     * Action CL 2003/10/27: Draft XML mime type thingy with Murata-san


    Ian Jacobs for Stuart Williams and TimBL
    Last modified: $Date: 2003/12/15 23:30:11 $

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Monday, 15 December 2003 18:40:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:02 UTC