IRC log of 28 Jan 2002 TAG teleconference

Note: This log has been edited slightly, primarily to remove interactions prior to discussion beginning in earnest, and after the meeting was adjourned. Some TAG scheduling information has also been removed.

Times are US East Coast.


<DanC> previous: 21Jan

<tim-mit> Zakim, who is here?

<Zakim> I see Stuart, TimBL, DanC, ??P8, TBray

<Zakim> +Ian

<tim-mit> Zakim, ??P8 is Norm

<Zakim> +Norm; got it

--> Norm ( has joined #tagmem

--> TimBray ( has joined #tagmem

<Ian> DanC, I would like to have RRSAgenda show up weekly.

<DanC> tim-mit, just say "is there anybody here who hasn't seen the agenda?"

<TimBray> what's the incantation to mute/unmute my phone?

<Zakim> +??P11

<TimBray> I thought it was #60 or some such

<DanC> some combination of 60# and 61# works too. (mnemonic: M0/M1)

<tim-mit> Zakim, ??P11 is Roy

<Zakim> +Roy; got it

<tim-mit> Zakim, who is here?

<Zakim> I see Stuart, TimBL, DanC, Norm, TBray, Ian (muted), Roy

<DanC> overload? is there some presumption that every TAG member reads every message to www-tag? I don't do that.

<Norm> it's a good question. i try to read enough of each thread to understand it


<Ian> * See a suggestion for TAG output from Tim Bray. This includes a strawman approach for issuing "Findings", more lightweight than W3C Rec process.

<Zakim> +DOrchard

<Ian> TB, this is under "How we work"

<Ian> TBL: I would like to come up with an outline of web arch and fill in the blanks.

<Ian> TBL: It's interesting to affix the issues that arise to various branches of the outline.

<Ian> TB: When do we bring the Recommendation process to bear?

<Ian> TB: There are probably a series of small issues. What do we do for them?

<Ian> TBL: Once we get a number of issues around a particular area, we can put forth a Rec.

<DanC> Q+

* Zakim sees DanC on queue

<DanC> q+

* Zakim sees DanC on queue

<DanC> q-

* Zakim sees no one on queue

<Norm> Is that a "speaker queue" feature, Dan?

<DanC> what I was gonna say (on when to do with our findings on mime types/namespaces): update "W3C data formats" note.

<DanC> yup, norm.

<Norm> kewl

<Ian> TBL: Are there good ideas for picking top items?

<Ian> DC: I think TBL should pick top 5 per meeting.

<Ian> TB: Let's pick up where we left off last week.

* Ian notes that that's around issue 16.

<Ian> TimBL: I think we should address 21 as well: rdfms-qname-uri-mapping.

<Ian> Norm: On my hot list as well.

* Norm agrees with Dan; updating the Data Formats not seems reasonable

<Ian> DanC: We don't have an obligation to match the throughput with the input.

<Ian> ...we should set expectations that we will only get to 2-3 a week.

<Ian> TBL: We should be responsive, however.

* Ian this part of the discussion is under "Issue tracking" on agenda....

<Ian> TB: The question is which ones get assigned issue numbers. A good way to start: they are all ignored by default, unless someone from the TAG requests that we put on agenda.

<Ian> DanC: Seconded.

<Ian> TBL: How do we guarantee that someone has read each message?

<Ian> DanC: We don't make that guarantee.

<Ian> Resolved: Add #21 to issues list.

<Ian> Action IJ: Add to issues list.

<Ian> ================

<Ian> Where we were last week:

<Ian> nsMediaType-3: Relationship between media types and namespaces?

<DanC> Re: [nsMediaType-3] Principles and corner cases

<DanC> From: Tim Bray (

<DanC> Date: Mon, Jan 21 2002


<Ian> DanC: In short: first two questions from xmlp wg were easy, last one hard.

<Ian> TB: Issue about when protocol header says something about a resource and the resource says something else.

<DanC> re charset, TimBL and Duerst put together a diagram

<DanC> from

* Ian loves his svg support in mozilla.

<Ian> TB: I don't have an SVG viewer on my desktop.

<Ian> TBL: Amaya or a plug-in for your browser.

<TimBray> How do you get Mozilla IRC to look at a different port? I couldn't figure it out

<DanC> Mozilla doesn't grok other ports, last I heard. bug.

<DanC> Q+

* Zakim sees DanC on queue

<DanC> to say: this diagram implies "charset" is registered for all mime types. Zat true?

<TimBray> q+

* Zakim sees DanC, TimBray on queue

--> Dave ( has joined #tagmem

<Dave> please repost the URL for the diagram..thx

<Ian> TBL reviews SVG diagram for determining character encoding.


<Ian> TBL: This is the flow diagram that includes the bits from MIME and from XML.

<Ian> ...I propose that we put this in our document and send to www-tag as input.

<DanC> hmm.. you can't always tell whether there's an xml encoding decl, can you? i.e. you have to guess an encoding and then check for an encoding decl in that encoding, right?

<Zakim> + +1.202.234.aaaa

<DanC> Zakim, +1.202.234.aaaa is PaulCinHotel

<Zakim> +PaulCinHotel; got it

<Ian> q+

* Zakim sees DanC, TimBray, Ian on queue

<TimBray> Dan, I think it works; check the XML rec appendix

<Norm> Yes, DanC, I agree. You have to check for "<?xml" in a variety of encodings

<Ian> DanC: First choice in this flow chart is "check if there's a charset". That presumes that charset means the same for all mimetypes. Is that the case?

<Ian> ...afaik, parameter names are local to each mime type.

<tim-mit> ACTION DanC check that

<TimBray> yeah, but after you've looked at the 1st 4 bytes, you pretty well know

<Ian> DanC: The EBCDIC part: if you don't know what the encoding is, you can never be certain that there isn't an encoding declaration.

<Ian> TB: You have to read 4 bytes in every charset you know, and see if there's an encoding declaration.

<Ian> TBL: The EBCDIC stuff is not standard.

<Ian> DanC: I can make up a new encoding right now and write an xml document in it.

<TimBray> no, you read the 1st 4 bytes once, then see if they make sense in each encoding you know

* Ian thanks TB for the optimization. ;)

<Ian> TB: The list you read out in conjunction with M.D. is correct. There's a real-world difficulty - your avg xml processor is more apt to be correct to know the encoding than the server is to guess from the suffix of the resource locally.

--> RRSAgent ( has joined #tagmem

* RRSAgent is logging

<Ian> TBL: What follows from flow chart: sender shouldn't specify a charset unless absolutely sure.

<Ian> TB: Yes.

<Ian> TBL: One of the ideas about putting the encoding at the top was that a proxy could do it.

<Ian> RF: I don't think a proxy can modify content type.

<Ian> TBL: Can it translate charset?

<Ian> RF: If you know what the charset is, by declaring it up front, this allows you to process media type in that charset alone.

<Ian> ..the basic problem is that media type scanners that are working at the level of the msg can't afford to know the 5 bazillion rules of charset analysis.

<Ian> ...if there is a charset defined for that particular media type, it's supposed to use it.

<Ian> ..but aside from text/*, no req that a media type have a charset.

<DanC> TBL: thanks, that clarifies: there's no requirement that a 3rd party be able to transcode..


<DanC> (i.e. change take JIS and convert to UTF-8). could break digital dignatures etc.

<Ian> DanC: This will work if I create and register a charset tomorrow.

<Ian> TBL: If not registered, xml spec says assume UTF-8 or UTF-16.

<Ian> TB: If it's UTF-16 needs the bomb in front

<Ian> [Discussion about gory details about detecting different ascii-based charsets...]

<Ian> TB: But this is dangerous in some cases. [Scribe didn't catch case]

<Ian> TB: I think we've almost disposed of this issue:

<Ian> a) Do we want to make a definitive statement on namespaces and media types? I don't want to.

<Ian> b) Should we say something about the case where the two disagree?

<Ian> TB: I think our position probably should be "This is an error. The MIME type is supposed to be right."

<Ian> DanC: Interesting case for me: if text/plain and has angle brackets, please do not interpret as HTML.

<Ian> ...if I put some stuff in a file that looks like HTML (e.g., <TITLE> in the first 200 chars) and send mime type of text/plain, I want users to see the plain text.

<Ian> TB: Even if you label as svg or xml, IE will render as HTML.

<Ian> PC: So, in the case of the MIME type, sounds like you are saying that you should assume that the server is doing the right thing.

<Ian> TB: Back in the days when everything was HTML, it might have been a forgivable sin for the client to correct something from the server.

<Ian> with XML I think we should take a harder stance. Also, this opens some glaring security holes.

<Ian> TBL: I agree.

<DanC> q+

* Zakim sees DanC, TimBray, Ian on queue

<TimBray> q-

<Ian> q-

* Zakim sees DanC, Ian on queue

* Zakim sees DanC on queue

<DanC> when we decide that we're serious about what the specs say, despite what popular software says, how can we get webmasterish folks to pay attention to us? can we exploit the QA wing of W3C somehow?

<Ian> PC: Are there other cases than text/plain that are important?

<DanC> "One problem with this is that some browsers sniff the document irrespective of MIME-type and display the content if it looks like HTML according to some heuristic[InetSDK], Appendix A. " --

<Ian> TB: I think it's not limited to text/plain.

<Ian> DC: Another case is java served as text/plain that's interpreted as java.

<Ian> DC: Microsoft SDK documents the <title> in first 200 bytes behavior.

<Ian> RF: A recent patch to MSIE removed that feature.

<Ian> ...a recent security fix in IE.

<Ian> PC: With MS hat loosely on, I'll track this down.

<Ian> DC: In 19 Dec version of MS SDK.

<Ian> (19 Dec 1997)

<tim-mit> q?

* Zakim sees DanC on queue

<Ian> DC: How do we get Webmasters to do the right thing?

<Ian> ...can we exploite the QA wing of W3C?

<Ian> IJ: Note "Common UA problems":

<Ian> IJ: We might have a "Common server problems"...

<Ian> TB: W3C has a track record of not engaging much in evangelism.

<Ian> DanC: Yes. Membership endorsed both QA Activity and TAG.

<Ian> TBL: We do do evangelism. We don't chase up miscreants.

<Ian> TBL: WAI is close to making lists of offending software.

<Ian> ...QA as well.

<Ian> PC: Do we have a QA Activity associated with Amaya?

<Ian> ...can we point people at Amaya?

<Ian> TBL: If we apply QA to Amaya, we won't have a wide impact.

<Ian> TB: That's not an effective way to get the word out.

<Ian> TBL: We've done evangelism for SVG by demonstrating it in Amaya. That's effective at the AC level.

<Ian> PC: You're interested, e.g., in getting people to do schemas the right way. On the schema home page,

<Ian> there's a link to a test suite with 10k test suites in it.

<Ian> DanC: We need to be similarly aggressive for this.

<Ian> TBL: Having a test area is a good idea.

* Ian notes that we also have a W3C Server.

<Ian> DanC: We could probably fit this test case in the HTTP/1.1 infrastructure.


<Ian> TB: I think we have consensus on the issues raised by the xml protocol WG.

<Ian> TBL: Proposed

<Ian> a) Start with TB text, the aforementioned SVG diagram, and another diagram.

<Ian> b) We publish in TAG space, and circulate pointer to chairs.

* DanC thinks a test case is worth a thousand words...

<Ian> TB: I don't know if I have write access to Web site.

<Norm> +1 on CVS!

<Stuart> Is there a coherent set of tools that we 'should' use?

<DanC> I'm CVS-ready today.

<Ian> IJ: Who is cvs-ready today?

<Dave> +1

* Zakim wonders where 1 is

<Ian> Roy, Paul

* DanC notes that danbri just sent a very well-formed request for 4 cvs accounts; suggests Ian do like he did.

* Norm notes I already have CVS access to, fwiw.

<Ian> Action TB: Put together text to resolve first three issues.

<Ian> Issues *-[1-3]

<Ian> -----

<Ian> Action item review:

<Ian> DO: Take a first stab at writing a policy to summarize resolution of issue w3cMediaType-1.

<Ian> Canceled since subsumed by TB's action.

<Ian> TBL: Get editable CVS space for TAG. Status: Pending.

<Ian> --------------------

<Ian> Upcoming meetings

<Ian> * Meeting information 12 Feb ftf now available. Please confirm for dinner if you will be at the meeting in person.

<Ian> *

<Ian> Regrets: DanC

<Ian> TB: I hope that DanC has cycles to attend ftf meetings in the future.

<Ian> DanC: I'm booked through June.

<Ian> DanC: I expect I can manage remote participation at upcoming meeting for a couple of hours.

<Ian> DanC: It would help to lock up a Sep date.

<Norm> Ian, while we're talking about it; regrets for dinner in 11 Feb; I'll be driving in the morning of 12 Feb

<Ian> thanks Norm

<Ian> Dinner 11th: TBL, SW, IJ only.

<Ian> I will follow up with respect to AB dinner.

<Ian> ---------------

<Ian> Mondays at risk:

<Ian> * 1 April (Easter Monday), 20 May (Victory Day in Canada), 27 May (Memorial Day in US), 3 June (Queen's Golden Jubilee Holiday in UK), 1 July (Canada Day in Canada), 26 August (Late Summer Holiday, UK), 11 November (Armistice Day in France).

* DanC refuses to answer this question on the grounds that it's machine computable (given my calendar) and should be answered by machine. ;-)

<Ian> Proposed to keep 1 April.

<Ian> Proposed to skip 27 May

<DanC> I'd rather we just look about 1 to 3 weeks ahead for telcons

<Ian> Re 20 May: TB ok.

<Ian> DO: I think in general we need to be flexible. I think that the TAG should go on, even if some people can't make it.

<Ian> TBL: Any problems with Feb meetings?

<Ian> TBL: Anyone can't make the 25th?

* DanC has glazed over

<Ian> TB: By default, the meetings should go ahead.

<DanC> Ian, pls don't give daynumbers without months, at least in writing

<Ian> Er, the context is clear: it's about Feb.

* Norm sends regrets for 1 Apr and 8 Apr.

<DanC> I object to "sender must include [issue] in the subject line."

<Ian> -----------------------------------

<Ian> Issue tracking and mailing list usage

<Ian> TBL: Trying to facilitate finding issues in the list.

<Ian> to do this automatically? Or just rely on manual tracking (IJ and TimBL)?

<Ian> DC: If something is important, someone will tell TBL that it's important.

<Ian> IJ: I'd like to set expectations that requests for broad reviews will likely be ignored; specific issues are more likely to get attention.

<DanC> someone in the TAG, in particular.

<Ian> PC: I'd like requests for review to include links to relevant discussion in a WG's archive.

<Ian> TBL: We should write down what's expected in an email that raises an issue.

<DanC> what's expected: pointer to where it's been discussed in the W3C, IETf, etc.

<DanC> (Ian, pls point to Larry's background pointers in the MIME type issue(s))

<Ian> Action IJ and TBL: Write down text requiring context when you raise an issue.

<DanC> q+

* Zakim sees DanC on queue

<tim-mit> q+ Stu

* Zakim sees DanC, Stu on queue

<DanC> q-

<Ian> IJ: seems to come down to: "We'll ignore unless we don't. Everything else is tips."

* Zakim sees Stu on queue

<tim-mit> q-

* Zakim sees Stu on queue

<DanC> yes, let's please use www-tag for the substantive discussion

<Ian> SW: Do we want huge discussions on www-tag, or do we want www-tag to be used for starting points?

<Dave> +1

* Zakim wonders where 1 is

<Ian> TB: I think strongly that we ought to have substantive debate in public on the list.

<Ian> DC, TBL: Agreed.

<Dave> DO agreed

<Ian> DC: I don't rely on threading. I rely on who sent the message.

<Ian> TB: I'll read things on the list that have an assigned issue number.

* Ian notes that "include issue number in subject" should be part of tips...

<Ian> RF: Should every WG and IETF be repeating all of their arguments on this list?

<Ian> ...this is a major overload problem.

<Norm> q+

* Zakim sees Stu, Norm on queue

<Stuart> q- Stu

* Zakim sees Norm on queue

<Ian> DanC: I am hoping that no one person can cause too much damage by sending too much mail. I'm hoping that a community will form around the TAG, that people will do their homework, that people will point to existing discussions, etc.

<Norm> q-

* Zakim sees no one on queue

* Norm agrees with what Dan said

<Ian> TB: When we get formal communications from other WGs, we probably should post a formal response whether we will look at or not.

<Ian> ---------------------

<Ian> Request for liaison:

<Ian> * Invitation to participate in UN/CEFACT ebTWG Architecture Group. Raised by Duane Nickull.


<Ian> Raised by Duane Nickull

<Ian> PC: Send to Chris Ferris, chair of the Web Services Arch gruop.

* DanC wonders if TimBL has license to discuss those meetings in public

<Norm> :-)

<DanC> I second PC's suggestion to delegate ebXML invitation to new Web Services WG chair

<Norm> q+

* Zakim sees Norm on queue

<Ian> NW: If a formal group asks us, we should have an obligation to respond (yes or no).

<Ian> ...treat formal requests for liaison politely.

<Ian> TBL: If people come with a specific issue?

<Ian> TB: Don't formalize too much:

<Ian> a) For official requests from w3c wgs, we must respond publicly.

<Ian> b) When we get requests from formal external bodies, we should think and SHOULD respond

<Ian> c) for individuals, default is that we are not obligated to respond (but will try)

<Ian> Resolved: Decline request to liaison with UN/CEFACT ebTWG arch group.

<Ian> Action PC: Draft response; will write public response within 48 hours.

<Ian> -------------------------

<Ian> Request to review XForms:

<Ian> PC: The statement should state that the TAG won't, as a matter of course, review things when they get to last call. Please bring specific architectural disputes (with context) instead.

<Ian> ....overriding comment : We MAY review many documents.

<Ian> TB: I agree with PC.

<Ian> Resolved: Add deprecating GET in xforms as an issue.

<DanC> whenToUseGet-NNN

<Ian> thanks dc

--> Roy ( has joined #tagmem

<Roy> was down

* DanC nominates stewart ro reply

<Ian> SW: What about if we respond by declining and asking for other specific items.

<Ian> Action SW: Respond to Art on www-tag.

<Ian> -------------------------------------

<Ian> Review of existing non-Rec arch documents:

<TimBray> unfortunately I have to go now

<Ian> *

<Ian> * XML in 10 points

<Ian> * What is a good standard?

<Ian> * Common User Agent Problems

<TimBray> bye

<DanC> ciao, Tim

<Ian> ciao

<DanC> bray

<Zakim> -TBray

<-- TimBray has quit ()

<Ian> TBL: I suggest as homework, and let people raise issues if they find any.

<Ian> DanC: Reading material before ftf?

* DanC considers requesting that my www-vs-engelbarts-requirements goes on the ftf reading list...

<Ian> Action IJ: Add links to this on public tag page (background reading)

* Ian will add RF's thesis as well.

<Ian> --------------------------

<Ian> Next meeting: 4 Feb 2001

<Zakim> -Roy

<tim-mit> Thank you everyone!