IRC log of tagmem on 2003-07-14

Timestamps are in UTC.

18:39:56 [RRSAgent]
RRSAgent has joined #tagmem
18:40:11 [Ian]
Ian has changed the topic to:
18:52:00 [DanC]
DanC has joined #tagmem
18:58:38 [Zakim]
TAG_Weekly()2:30PM has now started
18:58:45 [Zakim]
18:59:42 [Zakim]
18:59:45 [Zakim]
18:59:47 [Zakim]
18:59:53 [timbl__]
timbl__ has joined #tagmem
19:00:24 [Ian]
zakim, call Ian-BOS
19:00:25 [Zakim]
ok, Ian; the call is being made
19:00:26 [Zakim]
19:00:33 [Stuart]
Stuart has joined #tagmem
19:02:02 [Zakim]
19:02:14 [Zakim]
19:02:23 [Stuart]
zakime, ??p2 is me
19:02:30 [Stuart]
zakim, ??p2 is me
19:02:30 [Zakim]
+Stuart; got it
19:02:31 [Ian]
zakim, ??P3 is Paul
19:02:31 [Zakim]
+Paul; got it
19:02:35 [Chris]
Chris has joined #tagmem
19:02:39 [Ian]
zakim, Paul includes David
19:02:39 [Zakim]
I don't understand 'Paul includes David', Ian
19:03:02 [timbl__]
Zakim, Paul holds David
19:03:02 [Zakim]
+David; got it
19:03:20 [Ian]
Possible regrets NW
19:03:24 [Ian]
zakim, who's here?
19:03:24 [Zakim]
On the phone I see TimBL, ??P1, Ian, Stuart, Paul
19:03:25 [Zakim]
Paul has David
19:03:26 [Zakim]
On IRC I see Chris, Stuart, timbl__, DanC, RRSAgent, Zakim, Ian
19:03:39 [Ian]
zakim, ??P1 is Chris
19:03:39 [Zakim]
+Chris; got it
19:03:40 [Roy]
Roy has joined #tagmem
19:03:47 [Zakim]
19:04:00 [Zakim]
19:04:15 [Ian]
zakim, ??P3 is TimBray
19:04:15 [Zakim]
+TimBray; got it
19:04:17 [TBray]
TBray has joined #tagmem
19:04:24 [Roy]
Is there a better number to dial into for central Europe?
19:04:38 [Zakim]
19:04:41 [Chris]
better in what way?
19:04:45 [Roy]
19:04:48 [Chris]
19:04:55 [Roy]
okey doke
19:05:28 [Ian]
zakim, who's here?
19:05:28 [Zakim]
On the phone I see TimBL, Chris, Ian, Stuart, TimBray, DanC
19:05:29 [Zakim]
On IRC I see TBray, Roy, Chris, Stuart, timbl__, DanC, RRSAgent, Zakim, Ian
19:05:50 [Ian]
zakim, who's talking?
19:06:01 [Zakim]
Ian, listening for 10 seconds I heard sound from the following: Stuart (5%), TimBray (9%)
19:06:39 [Ian]
Chair SW, Scribe IJ
19:07:02 [DanC]
regrets NW
19:07:17 [Zakim]
19:07:19 [TBray]
19:07:20 [Chris]
19:07:31 [Ian]
zakim, ??P4 is Paul
19:07:31 [Zakim]
+Paul; got it
19:07:34 [Ian]
zakim, Paul holds David
19:07:34 [Zakim]
+David; got it
19:07:38 [Ian]
zakim, who's here?
19:07:38 [Zakim]
On the phone I see TimBL, Chris, Ian, Stuart, TimBray, DanC, Paul
19:07:39 [Zakim]
Paul has David
19:07:40 [Zakim]
On IRC I see TBray, Roy, Chris, Stuart, timbl__, DanC, RRSAgent, Zakim, Ian
19:07:40 [DanC]
some WebOnt folks had trouble generating a # tone a while back. I dunno how they worked around it
19:08:01 [Ian]
Accept corrected minutes of 30 Jun teleconference?
19:08:06 [Ian]
19:08:12 [Ian]
CL: I'm satisfied with 30 Jun mins
19:08:31 [Ian]
Resolved: 30 Jun mins accepted.
19:08:37 [Ian]
# Accept minutes of 7 Jul teleconference?
19:08:42 [Ian]
19:08:47 [Ian]
SW: Seem fine to me.
19:08:54 [Ian]
Resolved: 7 Jul mins accepted
19:09:01 [Ian]
# Accept this agenda?
19:09:06 [Ian]
19:09:22 [Ian]
19:09:31 [Ian]
zakim, mute me
19:09:31 [Zakim]
Ian should now be muted
19:09:46 [Ian]
DO: I have a hard stop in 51 minutes.
19:09:54 [Zakim]
19:10:15 [DanC]
Zakim, ??P5 is RoyF
19:10:15 [Zakim]
+RoyF; got it
19:10:15 [Ian]
zakim, ??P5 is Roy
19:10:16 [Zakim]
sorry, Ian, I do not recognize a party named '??P5'
19:10:53 [Ian]
zakim, unmute me
19:10:53 [Zakim]
Ian should no longer be muted
19:11:00 [Roy]
zakim, ?P5 is Roy
19:11:00 [Zakim]
sorry, Roy, I do not recognize a party named '?P5'
19:11:09 [Ian]
Resolved: Accept draft summary of TAG activity
19:11:15 [Ian]
19:11:31 [Ian]
Next meeting: 21-23 ftf meeting in Vancouver
19:11:40 [Ian]
Draft agenda:
19:13:40 [Ian]
SW: Comments on draft agenda?
19:15:38 [Ian]
zakim, mute me
19:15:38 [Zakim]
Ian should now be muted
19:16:39 [DanC]
SW: (1) namespace doc (2) LC pub. [pls put those meeting goals atop ]
19:17:29 [Ian]
SW: Two meeting goals
19:17:33 [Ian]
1) Arch doc decision
19:17:36 [Ian]
2) RDDL and namespaces
19:18:27 [Ian]
DC: I recommend incorporating reading list in the agenda.
19:19:46 [Ian]
TBL: Is the question of resolving httpRange-14 before last call on the agenda?
19:20:11 [Ian]
SW: I think that we've discussed this and decided httpRange-14 should neither be on the agenda nor a block to last call.
19:20:18 [Roy]
zakim, mute RoyF
19:20:18 [Zakim]
RoyF should now be muted
19:20:21 [Ian]
TBL: I'll try to work with RF during the breaks.
19:21:01 [Ian]
19:21:03 [Ian]
New issues?
19:21:33 [Ian]
1. Visibility of Web Services, raised by Mark Baker
19:21:33 [Ian]
2. Character model conformance, raised by TBL
19:21:33 [Ian]
3. Meaning of URIs in RDF documents, raised by TBL
19:21:35 [Ian]
19:21:40 [Ian]
Visibility of Web Services, raised by Mark Baker
19:22:06 [Ian]
DO: WSA WG has been talking about different arch styles and looking at properties achieved by application of various constraints.
19:22:37 [Ian]
DO: There is a section of the 14 May draft of the document that includes text about the property of "visibility" that Mark Baker disagrees with.
19:23:21 [Ian]
DO: In particular, in non-REST systems that are using XML, visibility comes from the fact that the content is in XML.
19:24:12 [Stuart]
19:24:28 [Ian]
DO: In a multi-protocol environment (with open and proprietary protocols), the assertion is that using XML-based queries to poke inside gives a certain level of visibility into what the message is doing.
19:24:42 [TBray]
q+ to admit he's confused and ask questions
19:24:44 [Ian]
DO: Mark is states that there is too much visibility (compared to REST interfaces).
19:25:03 [timbl__]
q+ to ask for a clarification of what Mark means by "restful web services", maybe with an example?
19:25:20 [Ian]
DO: The WSA is asserting that in multi-protocol environments, there are technologies for peeking into the XML structure. Mark asserts that the fact that you have to look inside means inferior visibility.
19:25:30 [Roy]
19:25:38 [Ian]
zakim, mute me
19:25:38 [Zakim]
Ian was already muted, Ian
19:25:50 [Ian]
TBray: I think there is no issue here.
19:25:58 [Stuart]
ack TBray
19:25:58 [Zakim]
TBray, you wanted to admit he's confused and ask questions
19:26:16 [Ian]
TBray: I think that MB subtext is that if you have a small set of verbs, this would provide a better mechanism for "visibility". I think that's probably wrong.
19:26:35 [Ian]
TBray: Intermediaries will peek inside; pretending that that won't happen is silly.
19:27:12 [Ian]
TBray: The term "visibility" is poorly defined. And pretending that there's another way to do this than peeking inside is [missed].
19:27:53 [Ian]
zakim, mute timbl_
19:27:53 [Zakim]
sorry, Ian, I do not see a party named 'timbl_'
19:28:01 [Ian]
zakim, mute TBL
19:28:01 [Zakim]
sorry, Ian, I do not see a party named 'TBL'
19:28:14 [Ian]
[DO seeks to clarify MB's point of view.]
19:28:52 [Stuart]
19:29:00 [Stuart]
ack timbl
19:29:00 [Zakim]
timbl__, you wanted to ask for a clarification of what Mark means by "restful web services", maybe with an example?
19:29:26 [Ian]
DO: Well-defined constrainted interface makes configuration simpler.
19:29:48 [Ian]
DO: Well-defined set of verbs improves performance.
19:29:50 [Chris]
q+ to ask if this is not inherrent in any xml protocol
19:29:56 [Ian]
zakim, who's here?
19:29:56 [Zakim]
On the phone I see TimBL, Chris, Ian (muted), Stuart, TimBray, DanC, Paul, RoyF
19:29:58 [Zakim]
Paul has David
19:29:59 [Zakim]
On IRC I see TBray, Roy, Chris, Stuart, timbl_, DanC, RRSAgent, Zakim, Ian
19:30:10 [Ian]
DO: I think that "visibility" is a combination of those two concepts.
19:30:44 [Ian]
DO: An example: say you are doing GET of a stock price - you look inside the URI and the HTTP verb and the intermediary can make a decision.
19:30:49 [Ian]
DO: If you look inside a POST....
19:31:08 [Ian]
DO: Two important things here:
19:31:27 [Ian]
1) Visibility is harder when there is more than one protocol.
19:32:40 [Chris]
no, its not harder. its a question of tunelling or not, and protocol independence or not
19:32:53 [Ian]
DO: Idea is to use xpath expressions to look inside xml content. HTTP as an application protocol does an excellent job for doing things like visibility. But people want to use otherp rotocols, too.
19:33:01 [Ian]
DO: Idea is to use xpath queries for any protocol.
19:33:14 [Ian]
DO: Mark doesn't address case of deployment of application across multiple protocols.
19:33:18 [Chris]
19:33:30 [TBray]
There's a fantasy here that firewall will loook at the message and say "it's a PUT and xyz is allowed to put, so I'll pass it through without looking at the XML message body." I don't buy it
19:34:09 [Ian]
TBL: What MB's point about using HTTP GET, or does he say you can use POST in a RESTful way?
19:35:22 [TBray]
over in son-of-RSS-land, we're converging on using POST for entry creation/update/deletion for reasons that seem good
19:35:47 [Roy]
Visibility is a variable property (like most properties). Things that are universal standards are inherently more "visible" than object-specific semantics, because you don't have to go look up the non-standard semantics. It is a design trade-off. There is no point in convincing Web Services to use a uniform interface, since the whole point of WSA is to develop programmable interfaces.
19:35:49 [Ian]
DC: I don't know what "visibility means.
19:35:52 [Stuart]
ack Dan
19:35:52 [Zakim]
DanC, you wanted to ask what visibility is
19:36:15 [Stuart]
ack Roy
19:36:18 [Ian]
DC: If this is only an issue of GET v. POST, I don't think we should adopt this as an issue.
19:36:59 [DanC]
that is: if this is GET vs. POST, that's issue 7.
19:36:59 [Ian]
RF: "Visibility" is what it sounds like - you can tell more about the message/interaction in some cases.
19:37:09 [Ian]
RF: I don' think this is a TAG issue.
19:37:22 [TBray]
19:37:23 [Ian]
RF: If you have a programmable interface, it's by definition not the generic interface.
19:37:57 [Ian]
RF: Visibility is not absolute; it's variable.
19:38:22 [Chris]
ack chris
19:38:22 [Zakim]
Chris, you wanted to ask if this is not inherrent in any xml protocol
19:38:31 [Ian]
RF: It's also true that an HTML form composition dialog is a very visible component, so it's easy for users to anticipate params by inspection.
19:38:57 [timbl_]
I do no think we have understood the issue.
19:39:04 [timbl_]
19:39:13 [Ian]
TBray: I suggest we write a note that says that Web services are inherently less visible than HTTP, this is why they are being worked on, we don't see an issue.
19:39:18 [Ian]
ack TBray
19:39:40 [Ian]
CL: To me, this is an issue of whether Web Services are opaque tunneling, or whether they add something.
19:39:57 [Ian]
zakim, who's here?
19:39:57 [Zakim]
On the phone I see TimBL, Chris, Ian (muted), Stuart, TimBray, DanC, Paul, RoyF
19:39:59 [Zakim]
Paul has David
19:40:00 [Zakim]
On IRC I see TBray, Roy, Chris, Stuart, timbl_, DanC, RRSAgent, Zakim, Ian
19:40:03 [Ian]
zakim, mute TimBL
19:40:03 [Zakim]
TimBL should now be muted
19:40:04 [timbl_]
Zakim, mute roy
19:40:04 [Zakim]
RoyF should now be muted
19:40:15 [timbl_]
Zakim, unmute me
19:40:15 [Zakim]
sorry, timbl_, I do not see a party named 'timbl_'
19:40:20 [timbl_]
Zakim, unmute timbl
19:40:20 [Zakim]
TimBL should no longer be muted
19:40:23 [Ian]
zakim, unmute TimBL
19:40:23 [Zakim]
TimBL was not muted, Ian
19:41:54 [Ian]
DO: I think that the point that needs to be made is that, in HTTP, GET/PUT/DELETE are not the end-all of communication.
19:42:00 [Ian]
DO: And other protocols are in use.
19:42:22 [Ian]
DO: So if you want to deploy an application across multiple protocols, I don't know whether you do have "better visibility" with core HTTP.
19:42:30 [Ian]
DO: You'll have to peek inside message bodies anyway.
19:43:00 [Ian]
DO: You'll want to standardize query...
19:43:00 [Chris]
if its opaque tunnelling, then peeking is bad
19:43:08 [Roy]
19:43:22 [Ian]
SW: Does anyone want to take this up?
19:43:33 [Ian]
19:43:37 [Ian]
- Thank Mark
19:43:50 [Ian]
- Say that the TAG doesn't feel this is an issue we want to take up.
19:43:59 [Chris]
if it adding 'xml headers' then its not peeking, its part of the (extended) protocol
19:45:43 [DanC]
ack danc
19:45:43 [Zakim]
DanC, you wanted to ask to move on; we don't need to decide anything. let the record show a lack of support for adding the issue to the issues list and that's it.
19:46:35 [Roy]
zakim, unmute RoyF
19:46:36 [Zakim]
RoyF should no longer be muted
19:47:18 [Ian]
DO: Should we say that the TAG supports what the WSA WG is doing?
19:47:20 [Ian]
TB, RF: No.
19:47:37 [Chris]
19:47:38 [Ian]
The TAG did not accept a new issue on this topic.
19:47:39 [Ian]
19:48:02 [Roy]
is my noise better when I am on local mute? (right now)
19:48:07 [Ian]
Discussion of text sent by David Orchard about extensibility.
19:48:14 [Ian]
19:49:02 [TBray]
hum but no banging
19:49:31 [Ian]
DO: Text is on versioning, how versioning relates to extensibility, backward and forward compatibility
19:49:41 [Ian]
DO: Also, handling unknown content.
19:49:59 [Ian]
DO: Also, mandatory extensions.
19:50:05 [Stuart]
19:50:12 [Ian]
DO: I received some comments about the last part on determinism.
19:50:21 [Ian]
zakim, mute Roy
19:50:21 [Zakim]
RoyF should now be muted
19:50:57 [TBray]
19:51:09 [Ian]
CL: The text seems good.
19:51:18 [Ian]
zakim, mute me.
19:51:18 [Zakim]
sorry, Ian, I do not see a party named 'me.'
19:51:20 [Ian]
zakim, mute me
19:51:20 [Zakim]
Ian was already muted, Ian
19:51:50 [DanC]
+1 for citing PNG spec. more precedents are good
19:51:53 [Ian]
CL: The PNG spec could also be cited as an example of a spec that includes forward/backward compatibility pieces.
19:52:07 [Ian]
CL: Text seems good and clear.
19:52:18 [Ian]
IJ: CSS also has for/back compatibility features.
19:52:19 [Stuart]
ack Chris
19:52:28 [Stuart]
ack TBray
19:52:54 [Ian]
TBray: I agree that first part is useful. However, I think that determinism section is (a) not architectural and (b) a design error in schemas and dtds.
19:53:26 [Ian]
TBray: Relax NG shows this can be done.
19:53:41 [Roy]
"should provide such a facility" --> "should be self-descriptive"
19:53:44 [Ian]
DO: I can live with dropping that section.
19:54:29 [Ian]
DO: Argument that I will continue to make in favor of keeping is that the "bad choice" for dtds and schemas should be cited as bad practice.
19:54:37 [Stuart]
ack Danc
19:54:37 [Zakim]
DanC, you wanted to 2nd striking determinism
19:54:43 [Ian]
DC: No, don't talk about determinism.
19:55:22 [Ian]
DC: I don't see this as architectural. Might be interesting to visit in a finding, but not in arch doc.
19:55:33 [timbl_]
q+ to pull out the extension by enveloping
19:55:39 [Ian]
TBray: I think it's useful to publish something somewhere about good practice, but not in arch doc.
19:56:24 [Ian]
TBL: "When to tunnel" is an interesting question.
19:57:10 [Ian]
TBL: I think that it's good to put in DO's text. There seems to be a confusion between document and document type in a few places.
19:57:58 [Ian]
I thought TBL meant "the proposed text in DO's email"
19:58:05 [DanC]
but you can't be sure.
19:58:56 [Ian]
TBL: Distinguish modified doc instances (tunneling) and layering...
19:58:59 [Ian]
19:59:04 [Ian]
ack timbl_
19:59:04 [Zakim]
timbl_, you wanted to pull out the extension by enveloping
19:59:11 [Stuart]
ack tim
19:59:25 [Ian]
DO to TBL: Some interesting comments; please suggest text.
19:59:34 [DanC]
ack ian
19:59:36 [Ian]
Action TBL: Send suggested text.
20:01:10 [Ian]
Resolved: IJ to incorporate DO's email minus section on determinism in Editor's Draft of ARch Doc.
20:01:25 [DanC]
with comments from timbl et. al. welcome
20:02:50 [Ian]
DC: I don't expect to read a full new draft between now and the mtg.
20:03:34 [Roy]
+1 for most-polished version
20:03:43 [Ian]
IJ: I can have a new draft tomorrow.
20:03:48 [Ian]
Action IJ: Publish Editor's draft tomorrow.
20:03:59 [Roy]
+2 for draft I can read on flight back to USA Thursday
20:03:59 [Ian]
TBray: I'll commit to having looked at it by Monday.
20:04:01 [Ian]
DC: I don't.
20:04:21 [Roy]
no progress
20:04:34 [Ian]
(Action RF 2003/06/02: Rewrite section 5. Section 5 is expected to be short.)
20:04:36 [DanC]
I'm happy for editor to polish all he likes, as long as I'm not expected to have it read before the meeting
20:04:39 [Ian]
Action SW 2003/07/07: Try to get TimBL to sign off on Paul's text. If SW able to reach TBL, SW/TBL send to AC as co-chairs. If not, have IJ send on behalf of TAG.
20:05:39 [Ian]
20:05:42 [timbl_]
20:08:27 [Ian]
TBL: I will look at this offline with SW (and IJ if necessary).
20:08:46 [Ian]
PC: Please do this asap. Preferably we want feedback from the AC before our ftf meeting.
20:08:55 [Ian]
TBray: I suggest this be sent by end of day...
20:09:49 [Ian]
TBL: I think discussion was more about "not covering" than "precluding".
20:10:12 [Ian]
DC: There's some data suggesting that the AC wanted "complete doc later" and we are doing "incomplete doc now".
20:10:19 [Ian]
DC: I agree that should be sent today.
20:11:29 [Ian]
Action TBL (with IJ support if necessary): Send email about TAG expectations re: arch doc to last call today.
20:11:31 [Ian]
20:11:40 [Chris]
20:12:05 [Ian]
Character model conformance, raised by TBL
20:12:11 [Ian]
20:12:17 [Ian]
20:12:22 [Ian]
ack Chris
20:12:42 [Ian]
CL: Our charter says we may point to architectural recs elsewhere rather than define.
20:12:59 [Ian]
TBL: Issue is the distinction between policy and architectural statement.
20:13:13 [Ian]
TBL: There was a suggestion that the TAG make the policy point and leave the arch issue in the char mod.
20:13:15 [Ian]
20:13:32 [Stuart]
20:14:00 [Ian]
CL: I would support the arch doc making the policy point.
20:14:01 [DanC]
ack ian
20:14:04 [Ian]
20:14:13 [Stuart]
ack danc
20:14:13 [Zakim]
DanC, you wanted to ask about how WGs discover this charmod bit
20:14:37 [Ian]
DC: To me this comes down to communication/enforcement. We have tried to keep the arch doc brief (so more people will read it).
20:14:43 [Stuart]
20:14:58 [Ian]
DC: We talked about char mod spec being split into three. As far as I know, they have not done it.
20:15:12 [Chris]
also, putting it in arch doc means it applies to everyone, not just 'w3c wgs'
20:15:14 [Ian]
DC: I don't expect everyone to read the entire (three parts) of charmod together.
20:15:20 [Ian]
DC: I support taking this up as an isuse.
20:15:27 [Chris]
+1 to taking up this issue
20:15:47 [Ian]
20:15:49 [Chris]
20:15:50 [Stuart]
ack Stuart
20:16:22 [Ian]
PC: Does this mean that our charter is wrong if we are only group with enforcement power...
20:16:25 [Ian]
20:16:41 [Ian]
ack Chris
20:17:08 [Ian]
CL: I think this is not merely procedural. I think that they don't really mean "Just W3C groups". I think they mean "Everyone should use this."
20:17:09 [Ian]
20:17:18 [Ian]
CL: They happened to use procedural methods to try to express this.
20:17:19 [timbl_]
q+ to say no, our charter is not wrong. Two things. (1) No one not even the TAG says "every one in W3C must do this and (2) ...
20:17:33 [Ian]
ack timbl_
20:17:33 [Zakim]
timbl_, you wanted to say no, our charter is not wrong. Two things. (1) No one not even the TAG says "every one in W3C must do this and (2) ...
20:17:51 [Ian]
TBL: Arch work is done in lots of places.
20:18:12 [Ian]
TBL: The TAG says "It's architecturally sound/unsound to do..." We don't limit ourselves to W3C WGs.
20:19:04 [Ian]
TBL: Various entities could make this statement. Reasons why the TAG should do this - a lot of the spec is technical (e.g., on canonicalization). The community has asked for "one place" to look. A two-liner would help the community, and the place for that is the arch doc.
20:20:46 [Ian]
CL: We should reiterate to I18N WG that we would like them to split their spec in 3.
20:21:08 [Chris]
based on different maturity levels
20:21:35 [Ian]
TBL: "Is is architecturally unsound to design systems that do not use the W3C Character Model?"
20:21:41 [Ian]
CL: Needs to be crisper than that.
20:22:10 [TBray]
20:22:21 [Chris]
of different sections
20:22:26 [Ian]
CL: E.g., granularity of changes and relation to requirement for normalization (e.g., after each modification in the DOM? Sum of modifications?)
20:22:52 [Ian]
TBL: "What arch issues are raised by the char mod spec?"
20:23:09 [Ian]
TBray: I would support TBL's first expression of the issue.
20:23:23 [Ian]
TBray: I wouldn't support investing more time in this issue until char mod has been split up.
20:24:07 [Ian]
Straw poll.
20:24:09 [Chris]
20:24:10 [TBray]
20:24:12 [DanC]
danc: yes, charModconformance
20:24:16 [Roy]
*shrug* abstain
20:24:22 [Stuart]
20:24:22 [Ian]
PC: Abstain
20:24:42 [Ian]
20:24:45 [Ian]
(for PC)
20:25:11 [Roy]
Punt on this until they finish their work.
20:25:33 [Ian]
TBL: Should we send a review that says until split we won't take this up.
20:25:35 [DanC]
20:25:54 [Ian]
Comments from NW:
20:25:57 [Ian]
20:26:22 [Ian]
TBray: Proposed (1) No consensus to take up (2) Discomfort on status of charmod draft.
20:26:33 [Chris]
*portions* of it are very uncooked
20:26:44 [Ian]
Coments were here:
20:26:46 [Stuart]
so noted
20:26:48 [DanC]
our comments are several links from issue 17...
20:26:50 [Ian]
20:26:51 [Chris]
and they have not responded to our change requests
20:27:42 [Stuart]
ack Tbray
20:27:45 [Ian]
TBL: Can we tell that that if they have a charmod doc, procedurally we would have no problem pointing to them.
20:27:47 [Ian]
20:28:49 [Ian]
CL: I would argue for the first part (normalization). Other parts would require CR first.
20:29:17 [Ian]
DC: Please move 17 to pending, not resolved.
20:29:35 [Ian]
Action IJ: Move issue 17 to pending rather than resolved.
20:29:56 [Ian]
Action DC: Remind I18N WG of what we are expecting.
20:30:14 [Ian]
(Regarding issue 17)
20:30:42 [DanC]
and yes, Chris, I'll be sending this (reminder re 17) on behalf of the TAG, not in my personal capacity.
20:30:55 [Zakim]
20:31:03 [Ian]
SW: TAG does not take up new issue regarding char mod.
20:31:38 [Ian]
SW: I don't expect we'll discuss third new issue at ftf meeting.
20:31:49 [Ian]
20:31:54 [Ian]
RRSAgent, stop