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
- Roll call: SW (Chair), TBL, NW, DO, TB, DC, RF, IJ (Scribe) . Regrets:
CL. Missing: PC
- Accepted the minutes of the 8 Sep
teleconf
- Accepted this agenda
- Next meeting 22 Sep teleconf. Regrets: SW (NW to Chair) and DO
- A distributed meeting is planned for 10 Nov (in response to email
from PC)
Upcoming events:
2. Technical
- rdfURIMeaning-39
- namespaceDocument-8
- deepLinking-25
- whenToUseGet-7
- contentTypeOverride-29
- [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.
Status of work on namespaceDocument-8.
- Completed action TB 2003/04/07: Prepare RDDL Note. Include in status
section that there is TAG consensus that RDDL is a suitable format for
representations of an XML namespace. Clean up messy section 4 of RDDL
draft and investigate and publish a canonical mapping to RDF. From 21
July ftf meeting. (done; see RDDL 4)
- Action PC 2003/04/07: Prepare finding to answer this issue, pointing to
the RDDL Note. See comments
from Paul regarding TB theses. From 21 July ftf meeting, due 31
August.
- Action PC 2003/09/08: Providing WebArch text as well for this
issue.
- Refer to draft TAG opinion
from Tim Bray on the use of URNs for namespace names.
[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)
- Completed action IJ 2003/07/21: Update Deep linking finding (i.e.,
create a new revision) with references to German
court decision regarding deep linking. No additional review required
since just an external reference. (Done)
- [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.
[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:
- Action RF 2003/06/02: Rewrite section 3. From 21 July ftf meeting, due
18 August.
- Action IJ 2003/06/16: Attempt to incorporate relevant bits of "Conversations and
State" into section to be produced by RF.
- Action TBL 2003/07/14: Suggest changes to section about extensibility
related to "when to tunnel".
- Action CL 2003/07/21: Create an illustration of two resources, one
designated by URI without fragment, and one designated by same URI with
fragment...
- Action TB 2003/08/18: Bring some Vancouver ftf meeting photos to IJ
attention (of whiteboard, re: CL action about illustration of two
resources)
- Action IJ, CL 2003/07/21: Discuss and propose improved wording of
language regarding SVG spec in bulleted list in 2.5.1.
- Completed action TBL 2003/07/21: Propose a replacement to "URI
persistence ...person's mailbox" in 2.6 and continue to revise TBL draft of section
2.6 based on TAG's 23 July discussion. (Done)
- Action DC 2003/07/21: Propose language for section 2.8.5 showing
examples of freenet and other systems.
- Action TB 2003/08/04: Write a definition of "XML-based"
- Action IJ 2003/08/04: s/machine-readable/something like: optimized for
processors, w/ defn that includes notion that it can be processed
unattended (by a person).
- Action TB and CL 2003/07/21: Propose a replacement sentence in section
3.2.2.1 regarding advantages of text formats. IRC log of 18
Aug teleconf suggested done, but can't find evidence.
The following action items were follow-up from the 22 July face-to-face
meeting in Vancouver:
- Identification and resources
- TBL 2003/08/21: Write replacement text for Moby Dick example in
section 2.6 (on URI ambiguity). Is this done in TBL's
draft?
- Representations
- TB, IJ 2003/08/21: Integrate findings. What does this mean?
2.4 Findings
See also TAG findings home page.
2.4.2 Draft findings that require more discussion
2.4.3 Expected new findings
- 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.
- 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.
Existing Issues:
2.5.4 Miscellaneous issues
3. Other actions
- Action IJ 2003/02/06: Modify issues list to show that actions/pending
are orthogonal to decisions. PLH has put the issues list in production;
see the DOM
issues list.
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/12/17 18:47:25 $