W3C | TAG | Previous: 8 Sep teleconf | Next: 22 Sep 2003 teleconf

Minutes of 15 September 2003 TAG teleconference

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

1. Administrative

  1. Roll call: SW (Chair), TBL, NW, DO, TB, DC, RF, IJ (Scribe) . Regrets: CL. Missing: PC
  2. Accepted the minutes of the 8 Sep teleconf
  3. Accepted this agenda
  4. Next meeting 22 Sep teleconf. Regrets: SW (NW to Chair) and DO
  5. A distributed meeting is planned for 10 Nov (in response to email from PC)

Upcoming events:

2. Technical

  1. rdfURIMeaning-39
  2. namespaceDocument-8
  3. deepLinking-25
  4. whenToUseGet-7
  5. contentTypeOverride-29

2.1 rdfURIMeaning-39

[Ian]
SW: Anything going on in rdfURIMeaning-39? I urge TAG to sign up to relevant mailing list.
DC: 8-9 people have introduced themselves on the mailing list. There are a few considered mail messages per week, which is a good thing. No call scheduled yet, but progress.

2.2 namespaceDocument-8

Status of work on namespaceDocument-8.

[Ian]

TBray: In RDDL 4, produced a status section. Haven't added canonical mapping to RDF yet.
DC: This action not done to my satisfaction until sent to www-tag.
[Norm]
timbl, i thought you commented on RDDL, but I can't find that comment. Am I mistaken? If not, where did you send it?
[Ian]
SW: What about statement about TAG consensus regarding suitability of RDDL as a format for ns docs?
TBL: I think the TAG consensus part belongs in finding rather than in RDDL spec (i.e., the statement in the status section of the RDDL draft).
TBray: I promise to do canonical mapping this week.
TBL: Please put as a normative appendix in the RDDL spec.
TBray: If you want to use it, it needs to exist (at least) independently.
[Zakim]
DanC, you wanted to ask for help finding "hello world" example
[Ian]
TBray: Yes, DC asked for hello world example, and I agreed with him.
Action TB: Add hello world example to a new draft this week.
NW to TB: Did you not also have to produce a DTD?
TBray: [Big sigh] I'll do this after we're agreed to the content.
Action TB: Produce schemaware once TAG has consensus on the syntax.
SW: What about impact of RDDL on arch doc?
TBray: PC is going to outline the finding. That will include a sound bite for inclusion in arch doc.
Action SW: Ping PC on status of his action.

2.3 Finding on deep linking (deepLinking-25)

[Ian]
TBray: How about "Public policy actions" instead of "Policies"?
IJ: A summary blurb in English might also be useful.
Action TB: Ask Lauren Wood to review German text to see if applicable.
Action IJ: Take back to Comm Team publicity of this document.
[DanC] I seem to remember that discussion of publicity around this finding.

Scribe summary: Acceptance of this revision is pending confirmation about the included reference.

2.4 Finding on when to use GET/POST (whenToUseGet-7)

[Ian]

DO comments: http://lists.w3.org/Archives/Public/www-tag/2003Sep/0039.html
TBray: WSDL WG aware of the finding, right?
DO: Yes. But they distinguish "GET" from safety. Support for GET seems too low-level. Customers are asking for a way to be able to mark an operation as safe.
DC: Yes, mark as "safe" and use the appropriate binding at the protocol level (i.e., depends on the protocol). Mark something at abstract level (e.g., "get stock quote") as safe; in protocol layer, it's bound to whatever the appropriate safe operations are.
TBray: In DO's note, are we still asking the WSDL WG to do something?
DC: You can't currently say in WSDL that an operation is safe.
SW: I agree with DC that marking safe should take place at abstract layer.
TBray: We are also asking for buy-in from WS community that safe operations should be done with GET.
DO: WSDL WG has accepted as a MUST that they have to accept the SOAP 1.2 binding. But I didn't see the marking of operations as safe being required.
TBray: I'm fine with our finding. I think we should ask the WS community to (1) investigate the possibility of building in a formalism to express the fact that an operation is safe and (2) encouraging, in specs, that developers implementing safe operations implement them with GET.
DO: I'm comfortable with (1).
TBray: I think we need to encourage people to use GET when they are using big globs of SOAP inefficiently. We have agreed with strong consensus that safe operations should be done with GET. If there are WGs that disagree, we need to explore this.
DO: I am happy with first para of 6 w.r.t. to comments from Noah. In SOAP 1.1, I think it was wrong to only describe a POST binding and to ignore GET. SOAP 1.2 gives equal treatment to GET/POST. I think that there are still a number of cases where, even if you have a safe operation, you still want to do with POST.
[DanC]
equal treatment? not for safe ops.
[Ian]
DO: I think it's moving too far to say "You should only do it this particular way...."
TBray: I agree with you for case of long URIs, etc.
SW: I think that we are haggling over this statement: "However, to represent safety in a more straightforward manner, it should be a property of operations themselves, not just a feature of bindings." Should we give more rationale for our request.
DO: I think our last sentence is fine. But I hear TB saying he wants something stronger.
[TBray]
http://diveintomark.org/archives/2003/09/08/msweb-rest
[Zakim]
DanC, you wanted to respond re "only" GET
[Ian]
DC: Our finding doesn't say "always use get"; it goes to great length. But the bottom line is it says "use get for safe operations". The SOAP spec doesn't give equal treatment for safe operations; it says use GET. Our position is pretty clear on this, it is "For safe operations, use GET.....except...."
[DanC]
(SOAP 1.2 to wit http://www.w3.org/TR/soap12-part1/#useofuris)
[Ian]
Noah's comments since (including replacement text):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0297.html
TBray: I'm inclined to accept these comments.
DC: I would like for more time to think about it.
TBray: Add some of NM's language (e.g., when I need to authenticate all the way into some application)
Action IJ: Incorporate NM comments and publish revision. If nobody shouts "Stop!" then we consider the finding accepted by the TAG.
TBray: Back to other point - our position on use of GET is pretty strong, so if there are WGs that are moving in the opposite direction, we should interact with them.
DO: I monitor WSDL WG. I'd like to point out next draft of finding to WSDL WG and say "I don't see this in your reqs. If WG does not intend to satisfy this requirement, please let's chat."
SW: I think that the WSDL's statement of their requirement is a misstatement of what we are saying.
DO: First para of section 6 relates to SOAP 1.2. As a result of changes to SOAP 1.2, WSDL says "support SOAP 1.2". There's a piece missing in WSDL, which I want to ask them about (concerning second para of section 6 in finding). I think that their issue is more related to SOAP 1.2, not an additional req.
TBray: It would be great if someone gave us pointers into relevant specs where this issue is relevant.
Action DC: Provide TAG with pointers into WS specs where issue of safe operations is manifest.
[Discussion of TAG / WS liaison]
DC: Have we told WSDL WG that we want their spec to look like this?
DO: There has been lots of dialog. This is a tough one since people have a certain mindset. I don't think that there's complete understanding of the issues on both sides yet.
[DaveO]
Issue R128 : InterfaceBindings SHOULD provide for mapping Message content to WSDLService location URIs. (From DO. Last discussed 22 Jan 2003.)
[Ian]
Action DO: Ask WSDL WG to look at finding; ask them if marking operations as safe in WSDL is one of their requirements.
[DanC]
cool. Move issue 7 to pending state.

2.5 Finding on content type (contentTypeOverride-29)

[Ian]

IJ to RF: Could you suggest replacement text for your points?
[Roy]
I can suppy text
[Ian]
TBray: I'm arguing that in the case of XML, it's actively harmful to provide a charset unless you are really certain you're right.
RF: My problem has to so with some XML variations, such as XHTML. E.g., if a system is set up to do a security check on content, they will tag it with appropriate charset for that document, whether they are certain whether the content in the document is really of that charset. Their instructions to the client is to ONLY use a particular charset.
TBray: In what scenario is it desirable to tell the client to only use one charset.
RF: There are security holes in some browsers that make them vulnerable when trying to do char code switching.: Server tells browser "Only interpret this data in the following way." Not all xml parsers are correct xml parsers.
[DanC]
client vulnerability, but our advice to servers might make it worse
[Ian]
TB summarizing:
- I send xhtml text to browser
- I send as text/html, so no problem sending charset.
- If I send as application/xhtml+xml ....
RF: No charset param.
TBray: Or does it per RFC 3023? If there's no charset param on application/xhtml+xml, then I'm fine.
[DanC]
s/ascii/iso-latin-1/
[Ian]
[Diff is between sending charset for text/html and application application/xhtml+xml]
TBray: I think we agree that sending xml as text/* is a likely source of difficulties. I think we are saying that if we send as application/* that it's a bad idea to send charset.
[Zakim]
DanC, you wanted to ask if we've told the WSDL WG what we want from them and to and to check if he understood Roy
[Ian]
RF: I am for removing charset parameter for application/*
TBray: We could ask authors of 3023 to update it per the changes we are asking for. Section 3.2 of 3023: optional charset param. "Strongly recommended"
RF: Ask on www-tag if we should remove charset from application/* types. Meanwhile, don't require the server to make a judgment call on the content type. Server doesn't have a brain.
TBray: I note that in draft finding we already grumble about what 3023 says
RF: We can ask authors of 3023 on www-tag why those types have charset param.
Action TB: Draft a Note to authors of RFC 3023 cc'ing www-tag about concerns regarding charset asking about chances of getting this fixed.
IJ: How does this affect this sentence: "For this reason, servers should only supply a character encoding
header when there is complete certainty as to the encoding in use."
RF: If you keep the sentence, it should say that server software should only supply charset when there's complete certainty about the character encoding used within the body.
Action RF: Propose alternative text to other points in RF's original email.
RF: I'll do this today.

2.3 Architecture Document

Reference draft: 1 August 2003 Editor's Draft of the Arch Doc. See also rewrite of the abstract and introduction.

2.3.1 Review of actions related to Architecture Document

Open action items:

The following action items were follow-up from the 22 July face-to-face meeting in Vancouver:

2.4 Findings

See also TAG findings home page.

2.4.2 Draft findings that require more discussion

2.4.3 Expected new findings

  1. contentPresentation-26: Action CL (and IJ from ftf meeting) 2003/06/02: Make available a draft finding on content/presentation. From 21 July ftf meeting, revision due 8 August.
  2. Action IJ 2003/06/09: Turn TB apple story into a finding.

2.5 Issues

The TAG does not expect to discuss these issues at this meeting.

2.5.1 Identifiers (URIEquivalence-15 , IRIEverywhere-27)

2.5.2 Qnames, fragments, and media types(rdfmsQnameUriMapping-6, fragmentInXML-28, abstractComponentRefs-37, putMediaType-38)

2.5.3 New and other Issues requested for discussion. (mixedUIXMLNamespace-33, RDFinXHTML-35, siteData-36 plus possible new issues)

Existing Issues:

2.5.4 Miscellaneous issues

3. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/12/17 18:47:25 $