13:57:42 <RRSAgent> RRSAgent has joined #wam
13:57:42 <RRSAgent> logging to http://www.w3.org/2010/02/25-wam-irc
13:57:57 <ArtB> RRSAgent, make log public
13:57:59 <ArtB> ScribeNick: ArtB
13:58:00 <ArtB> Scribe: Art
13:58:02 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0707.html
13:58:04 <ArtB> Chair: Art
13:58:05 <ArtB> Meeting: Widgets Voice Conference
13:58:07 <ArtB> Date: 25 February 2010
13:58:10 <Zakim> IA_WebApps(Widgets)9:00AM has now started
13:58:16 <Zakim> +[IPcaller]
13:58:31 <Zakim> +Art_Barstow
13:58:47 <Zakim> +??P15
13:58:54 <arve> Zakim, [IPcaller] is me
13:58:54 <Zakim> +arve; got it
13:58:59 <fjh> zakim, ??P15 is fjh
13:58:59 <Zakim> +fjh; got it
13:59:03 <ArtB> Present: Art, Arve, Frederick
13:59:25 <ArtB> Regrets: Marcin
13:59:37 <Zakim> +Marcos
13:59:45 <ArtB> Present+ Marcos
14:00:04 <fsasaki> fsasaki has joined #wam
14:00:24 <Zakim> +aphillip
14:00:48 <arve> Zakim: calling in?
14:00:54 <ArtB> Present+ Addison
14:00:58 <arve> Marcos: ^ calling in soon?
14:02:54 <r12a> r12a has joined #wam
14:02:59 <r12a> zakim, dial richard please
14:03:02 <Zakim> ok, r12a; the call is being made
14:03:03 <Zakim> +Richard
14:03:14 <ArtB> Present+ Richard
14:03:16 <Zakim> +??P9
14:03:22 <Zakim> +[IPcaller]
14:03:25 <ArtB> Present+ Felix
14:03:31 <ArtB> Present+ Robin
14:03:45 <r12a> zakim, who's here ?
14:03:48 <Zakim> On the phone I see arve, Art_Barstow, fjh, Marcos, aphillip, Richard, felix (muted), [IPcaller]
14:03:54 <Zakim> On IRC I see r12a, fsasaki, RRSAgent, arve, Zakim, aphillip, MikeSmith, Steven, ArtB, Marcos, darobin, tlr, shepazu, chaals, fjh, anne, trackbot, steve
14:04:15 <ArtB> Topic: Review and tweak agenda
14:04:20 <ArtB> AB: the agenda was posted on Feb 24 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0707.html ). Given some guests are here today, we will move Announcements to the AOB part of the agenda. Any other change requests?
14:04:46 <ArtB> [ none ]
14:04:48 <ArtB> Topic: P&C spec: ITS
14:04:56 <ArtB> AB: an issue with the P&C spec is what to do about the Optional ITS support. On February 22 Marcos sent a proposal to WebApps and I18N Core WG ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0681.html ). 
14:05:03 <Bryan> Bryan has joined #wam
14:05:17 <ArtB> AB: to help us all get on the same page here, let's start with Marcos - what's the problem?
14:05:31 <Zakim> +Bryan_Sullivan
14:05:40 <ArtB> Present+ Bryan
14:05:53 <ArtB> MC: the config doc permits pieces of metadata
14:06:05 <Steven> zakim, dial steven-work
14:06:05 <Zakim> ok, Steven; the call is being made
14:06:07 <Zakim> +Steven
14:06:10 <ArtB> ... some of that metadata could be marked up with ITS elements
14:06:35 <ArtB> ... not sure what the UA is supposed to do
14:06:40 <r12a> q+
14:06:47 <ArtB> ... We have one partial impl of ITS
14:07:03 <ArtB> ... so we are concerned about how to move the spec forward
14:07:56 <ArtB> RI: there are a couple of things here
14:08:02 <ArtB> ... one issue is bi-di support
14:08:18 <ArtB> ... the other has to do with how the markup is used
14:08:37 <ArtB> MC: yes, I agree
14:08:38 <darobin> +1
14:08:39 <fsasaki> q+
14:08:44 <ArtB> ... we don't want to remove the capability
14:08:47 <darobin> ack r12a 
14:09:07 <ArtB> RI: then we should talk about bi-di support versus ITS support
14:09:45 <ArtB> RI: do you now have a dir tag without an its prefix?
14:09:56 <ArtB> MC: there is some confusion about the syntax
14:10:13 <ArtB> ... we don't define dir in the widget ns
14:10:46 <ArtB> ... some confusion from the author's point of view
14:11:01 <ArtB> RI: from our PoV, very imp to support bi-di
14:11:10 <ArtB> ... but dont think you need dir: before span 
14:11:32 <ArtB> ... spec says you can use your own tag
14:11:34 <darobin> s/you need dir: before span/you need its: before dir or span/
14:11:57 <ArtB> MC: that's what we want
14:12:04 <ArtB> ... don't want to add another namespace
14:12:08 <ArtB> AP: that's OK with us
14:12:21 <ArtB> ... there are lots of grammars that have span elements and dir attrs
14:12:33 <ArtB> ... import the functionailty into your own spec
14:12:49 <fsasaki> felix: agree with what Richard said
14:13:00 <fsasaki> http://lists.w3.org/Archives/Public/public-i18n-core/2010JanMar/0041.html
14:13:01 <darobin> ack fsasaki 
14:13:07 <ArtB> FS: want to second what RI and AP said
14:13:31 <darobin> s/http:/-> http:/
14:13:37 <ArtB> ... follow the above link
14:13:51 <ArtB> ... to see an example you could follow
14:14:19 <ArtB> RB: so if we add span and dir to our namespace
14:14:27 <ArtB> ... do we then add an ITS rule?
14:14:41 <ArtB> FS: I think it would be useful
14:14:51 <ArtB> ... need to support the bi-di feature
14:15:08 <ArtB> RI: let me summarize
14:15:33 <darobin> s/do we then add an ITS rule/do we then add an ITS rule to that specification so that it can be plugged into ITS-supporting software easily and capture the intent clearly/
14:15:45 <fsasaki> s/need to support the bi-di feature/but most important aspect is to support the bi-di feature, as richard said/
14:15:59 <ArtB> ... ITS spec: tells the set of features needed including bidi; gives advice for translators; provides a mech one can follow to define the tags needed
14:16:14 <ArtB> ... and Felix's example illustrates that
14:16:34 <Marcos> +q
14:16:54 <ArtB> MC: hearing good use cases
14:17:09 <ArtB> ... would be good to expand on how to use ITS functions
14:17:10 <darobin> ack Marcos 
14:17:20 <ArtB> ... think we should put that in a separate spec
14:17:29 <ArtB> AP: I'm a little hesitant to separate it
14:17:50 <ArtB> ... by splitting, it tends to invite people not to implement it
14:17:59 <ArtB> RI: yes, I tend to agree
14:18:09 <ArtB> ... something like bi-di really needs to be there
14:18:25 <ArtB> MC: so if we introduce span and dir, then we would need to make it mandatory
14:18:27 <darobin> q+ to ask about unicode-based directionality
14:18:31 <ArtB> ... currently, it is optional
14:18:48 <Steven> Is there a link to the place where it says ITS is optional?
14:18:56 <ArtB> AP: providing proper bidi markup is very importatnt
14:19:18 <ArtB> ... the way you implement it is up to you
14:20:25 <ArtB> ... it is key to have the right syntax
14:20:28 <fsasaki> q+ to provide an example from svg tiny http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup
14:20:33 <ArtB> ... and provide enuf info for implementors
14:20:36 <darobin> ack m
14:20:39 <darobin> ack darobin 
14:20:39 <Zakim> darobin, you wanted to ask about unicode-based directionality
14:20:50 <ArtB> RB: 3 small things ...
14:21:03 <ArtB> ... I think there is a strong consensus to support bidi
14:21:14 <ArtB> ... but we have lots of pressure to release the spec now
14:21:42 <ArtB> ... we have made promises to proceed from CR to REC as soon as possible
14:22:10 <ArtB> ... I have a question about how to express the value of bidi markup versus using unicode markers for directionality
14:22:26 <ArtB> ... Unicode chars can be used so not clear we need anything else
14:22:59 <ArtB> ... 3rd, re API, we return a string that may contain the span element. How is that handled?
14:24:04 <ArtB> RI: we are discussion bidi in the context of HTML
14:24:20 <ArtB> ... they are pushing for markup rather than the Unicode chars
14:24:28 <ArtB> ... authors can't see them
14:24:41 <ArtB> ... very difficult with paragraph endings
14:24:46 <ArtB> ... also inheritance probs
14:24:55 <ArtB> ... so markup is cleaner
14:25:28 <ArtB> AP: RI hit the main points
14:25:40 <ArtB> ... dir attr does have a certain amount of scope
14:25:52 <ArtB> ... if have structure element, can set base directionality
14:26:10 <ArtB> ... [ missed stuff about blocks of stuf ... ]
14:26:30 <ArtB> ... e.g. can say widget name is LtoR or RtoL 
14:27:07 <ArtB> ... The unicode markers are more relevant for paragraphs
14:27:43 <r12a> actually unicode markers are only inline indicators
14:27:59 <ArtB> ... adding markers for LtoR langs can be a pain for authors
14:28:12 <r12a> (which makes for much more work on the authors part to support them too)
14:28:21 <ArtB> RB: so markup is better for authoring
14:28:49 <darobin> ... and structure
14:29:03 <ArtB> RI: inheritance is also important
14:29:23 <ArtB> ... if writing a config file, want to put dir at the top and then not have to do it again
14:29:35 <ArtB> ... if use markers, it's a lot more work for the author
14:29:48 <ArtB> ... inheritance via markup is much more workable for authors
14:30:06 <Marcos> +q
14:30:07 <darobin> API example: <name>Foo <span dir='rtl'>esrever</span> Bar</name> when that value is retrieved with var nameString = widget.name;
14:30:18 <darobin> ack Marcos 
14:30:22 <darobin> ack fsasaki 
14:30:22 <Zakim> fsasaki, you wanted to provide an example from svg tiny http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup
14:30:39 <ArtB> MC: question about this when xml:lang is used
14:30:50 <ArtB> ... does the lang give a hint about dir?
14:31:07 <ArtB> AP: xml:lang can be a hint about what content will follow
14:31:14 <ArtB> ... but it does not define directionality
14:31:32 <ArtB> ... we discouage using xml:lang as an indicator for directionality
14:32:41 <ArtB> ... we have some examples
14:33:01 <ArtB> RI: the function of lang and dir are fundamentally different
14:33:07 <ArtB> MC: ok, thanks for clarifying
14:33:17 <fsasaki> felix: the svg tiny example http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup demonstrates how ITS markup is integrated into a language (SVG) *without changing the behavior of svg* - but the markup is still important for applications which process svg, e.g. translation tools. So adding the markup does not mean IMO that you need to go back in the w3c process. Also, regarding "re API,...
14:33:19 <fsasaki> ...we return a string that may contain the span element. How is that handled?": not sure if there is a need to keep the span element in the DOM, since it is not relevant for widget processing.
14:33:28 <ArtB> FS: I just entered what I wanted to say
14:34:52 <ArtB> ... don't think the P&C spec should need to define how to process text bidi marked text
14:35:16 <ArtB> RB: it's not so much about the DOM
14:35:26 <darobin> <name>Foo <span dir='rtl'>esrever</span> Bar</name> when that value is retrieved with var nameString = widget.name;
14:35:32 <ArtB> ... the algorithm ignores stuff it doesn't understand
14:36:15 <ArtB> ... re the example I entered above, not sure how to expose the string so it can be displayed properly later on
14:36:22 <ArtB> ... don't want the info to be lost
14:36:52 <ArtB> AP: the API would need to preserve directionality
14:37:24 <ArtB> RB: so if the API returns a human readable string, what do we return?
14:37:31 <fsasaki> felix: agree with directionality - only no need to preserver any other ITS information derived from the markup (e.g. the "translate" flag)
14:38:04 <ArtB> RI: if using JS, then could use markers
14:38:09 <ArtB> ... and then do the conversions
14:38:43 <ArtB> AP: would expect name element to have the dir attr
14:39:11 <ArtB> ... can then have an api to get the dir
14:40:26 <ArtB> MC: do we insert the unicode control points or not?
14:40:26 <darobin> RB: the issue is indeed for JS APIs, for instance for the generation of About boxes — the JS does not have access to the original XML, just the API on top of it
14:40:47 <ArtB> AP: if you have other markup, then want to turn the markup to a string
14:41:04 <ArtB> ... need to be careful; don't want to loose info
14:41:15 <ArtB> ... and don't want the API to be too difficult
14:41:24 <ArtB> ... need to work thru the main use cases
14:41:33 <ArtB> ... to determine what soln to use
14:41:43 <ArtB> MC: our case is mainly human readable text
14:42:17 <ArtB> AP: may need a separate API to get directionality
14:42:43 <darobin> ACTION Robin to produce examples of API retrieval of human-readable text with directional information
14:42:43 <trackbot> Created ACTION-495 - Produce examples of API retrieval of human-readable text with directional information [on Robin Berjon - due 2010-03-04].
14:43:00 <arve> WTF?
14:43:04 <Zakim> -arve
14:43:29 <ArtB> MC: don't want to loose directionality of the span
14:43:39 <ArtB> s/MC: don't/AP: don't/
14:43:42 <Zakim> +arve
14:43:56 <ArtB> RB: I'll need to look into this API problem
14:44:05 <ArtB> ... I will then send it to you for review
14:44:12 <ArtB> ... if that sounds OK
14:44:17 <ArtB> RI: sound good
14:44:24 <ArtB> AP: yes
14:44:29 <ArtB> MC: I'll help with the examples
14:44:39 <Marcos> proposal http://dev.w3.org/2006/waf/widgets-bidi/
14:45:14 <ArtB> AB: what is this Marcos?
14:45:33 <ArtB> MC: it's a separate spec for widget directionality
14:45:50 <ArtB> ... need to clearly define what needs to be done with bidi
14:46:10 <ArtB> ... already think this proposal needs to have some changes based on today's discussion
14:46:37 <ArtB> ... Based on the examples, will be able to update the API 
14:46:52 <ArtB> RI: may have a similar issue with lang
14:47:09 <ArtB> ... it can be on spans, and other places
14:47:20 <ArtB> MC: yes, we need to look at the various cases
14:48:07 <ArtB> RI: there are no unicode markers for lang
14:49:28 <ArtB> AB: so if we were to move the ITS functionality to a separate spec, would that be objectionably? 
14:49:46 <ArtB> AP: yes, I think the I18N Core WG would find that objectionable
14:50:03 <ArtB> ... concerns about it not getting implemented and others I mentioned ealier
14:50:28 <ArtB> MC: yes, understand; we have very little support for it now from implementors
14:51:07 <ArtB> RB: it is much easier for us to tell people to implement a small separate spec then it is to implement an Optional part of a spec
14:51:21 <ArtB> AP: the attributes are not optional
14:51:31 <ArtB> ... the effect they have is sometimes not optional
14:51:37 <ArtB> ... there is a right thing to do
14:52:41 <ArtB> MC: we could do this in a seperate spec and in P&C spec, say this the Widget BiDi spec SHOULD/MUST be implemented
14:52:48 <ArtB> ... want to finish P&C
14:53:17 <ArtB> ... we have a good test suite and we can add some ITS tests
14:53:38 <ArtB> ... I think that would address the concerns you expressed
14:53:55 <ArtB> ... then we can add additonal use cases as needed
14:54:32 <ArtB> RI: if put span and dir in the grammar in P&C and then specify them in a separate spec
14:54:41 <ArtB> MC: yes, we can do that
14:55:52 <ArtB> RI: are you saying that in the P&C spec, define the span and dir as mandatory and then specing them separately?
14:55:53 <ArtB> MC: yes
14:55:59 <ArtB> RB: I think that would be OK
14:56:13 <ArtB> RI: I think we would say that isn't the preferred plan 
14:56:31 <ArtB> RB: I agree it's not our preferred plan either but we need to ship the spec
14:56:38 <Steven> Which argues against a three week LC by  the way
14:56:41 <fsasaki> felix: agree with that plan - not preferred, but still ok
14:57:06 <ArtB> AP: will be painful if you take it away and then try to add it later
14:57:48 <ArtB> AB: then this plan wouldn't be ideal but would meet the I Can Live With It Test
14:58:22 <ArtB> RI: the examples we've seen today aren't real convincing and I can supply others
14:58:25 <ArtB> RB: that would be great
14:58:45 <darobin> ACTION Marcos to email I18N to ask for better examples, edit P+C to match decision
14:58:45 <trackbot> Created ACTION-496 - Email I18N to ask for better examples, edit P+C to match decision [on Marcos Caceres - due 2010-03-04].
14:59:10 <ArtB> SP: wasn't clear on the Core feedback loop
14:59:30 <ArtB> RB: we got some feedback to use markers
14:59:42 <ArtB> ... but we we want to keep moving the spec forward
14:59:59 <darobin> .... we should have done the i18n tests first
15:00:05 <fsasaki> zakim, unmute Felix
15:00:06 <Zakim> felix should no longer be muted
15:00:15 <ArtB> Topic: DigSig spec: C14N
15:00:16 <Zakim> -aphillip
15:00:18 <Zakim> -Richard
15:00:20 <Zakim> -felix
15:00:22 <Zakim> -Steven
15:00:32 <fsasaki> fsasaki has left #wam
15:00:35 <ArtB> AB: on Feb 12, Marcos started a thread related to the Canonical XML spec ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0595.html ). There was a related follow-up by Henri Sivonen ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0679.html ) and Andreas Kühne again mentioned his company's service ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0596.h
15:00:36 <ArtB> t
15:00:38 <ArtB> ml ).
15:01:18 <ArtB> AB: I don't think any new information has been added to the discussion about using using XML Signature for widget signing.
15:01:49 <ArtB> AB: do we have an issue to discuss?
15:01:58 <fjh> I saw nothing new in the discussion
15:02:01 <ArtB> MC: no I don't think so
15:02:23 <fjh> q+
15:02:58 <fjh> q-
15:03:13 <r12a> r12a has left #wam
15:03:49 <ArtB> MC: I talked to our guys but we are OK with proceeding as already agreed
15:04:26 <ArtB> AB: proposed resolution: we continue as previously agreed with Dig Sig spec
15:04:32 <ArtB> AB: any objections?
15:04:36 <ArtB> [ None ]
15:04:52 <ArtB> RESOLUTION: we will continue as previously agreed with Dig Sig spec
15:05:08 <ArtB> Topic: Interface spec: openURL security considerations
15:05:14 <ArtB> AB: on Feb 18, Marcos asked for input on openURL security considerations ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0659.html ). What's the status?
15:06:08 <ArtB> MC: I expect Opera will provide some input and I will reflect other comments
15:06:30 <ArtB> ... there are some issues with this method so we need to be cautious
15:06:55 <ArtB> AB: will addressing the issue require normative changes to the spec?
15:07:00 <ArtB> MC: no, I don't think so
15:07:11 <ArtB> ... we need to provide some more guidance for implementors
15:07:34 <ArtB> AB: I think we're OK here
15:07:43 <ArtB> MC: yes, I'll refine the informative text
15:07:54 <ArtB> Topic: Interface spec: resolution of relative URIs
15:08:42 <ArtB> AB: on Feb 24, Arve asked a question in IRC re how relative URIs are resolved ( http://krijnhoetmer.nl/irc-logs/webapps/20100223 ).
15:09:45 <ArtB> Arve: the spec has some text about relative URIs 
15:10:45 <ArtB> ... may have a conflict between openURL and similar APIs like window.open
15:11:49 <ArtB> ... [ Arve make a proposal that is not minuted ... ]
15:12:01 <ArtB> ... must look at the resolved URI and not the string
15:12:11 <ArtB> MC: yes, that makes sense; I can work with Arve on this
15:12:24 <ArtB> ... that change would simplify some things as well
15:13:47 <ArtB> AB: is this going to be editorial change or something more substantial?
15:13:58 <ArtB> MC: I think this is more of an editorial change
15:14:14 <ArtB> ... but after I am done editing we can decide if the change is more substantial
15:14:22 <ArtB> Arve: I agre this is more editorial
15:14:59 <ArtB> Topic: View Modes Media Feature spec: LC ToDo list
15:15:08 <ArtB> AB: on Jan 14, Marcin posted a list of 4 open issues for the VMMF spec ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0170.html ). We discussed this list on Jan 21 ( http://www.w3.org/2010/01/21-wam-minutes.html#item06 ). 
15:15:42 <ArtB> AB: Since then were no follow-ups, want to go thru the list and get an understanding about what needs to be done to address the issues.
15:15:53 <ArtB> AB: note for the record that Marcin sent regrets for today
15:16:37 <Marcos> zakim, who is making noise?
15:16:48 <Zakim> Marcos, listening for 10 seconds I heard sound from the following: arve (8%), Art_Barstow (18%), [IPcaller] (42%), Marcos (35%)
15:17:40 <fjh> zakim, who is here?
15:17:42 <Zakim> On the phone I see Art_Barstow, fjh, Marcos, [IPcaller], Bryan_Sullivan, arve
15:17:48 <Zakim> On IRC I see Bryan, RRSAgent, arve, Zakim, MikeSmith, Steven, ArtB, Marcos, darobin, tlr, shepazu, chaals, fjh, anne, trackbot, steve
15:18:05 <ArtB> AB: what is the priority of this spec?
15:18:18 <ArtB> RB: I can take a look at this?
15:18:33 <darobin> ... it's a question of what the WG's priorities are
15:18:36 <ArtB> s/look at this?/look at this/
15:19:13 <Marcos> darobin to view modes!
15:19:32 <ArtB> AB: if this spec is getting implemented, we need to freeze it
15:19:45 <ArtB> MC: we need someone to take editorial control
15:19:59 <ArtB> ... my priority is Update spec at the moment
15:20:34 <arve> zakim, unmute me
15:20:34 <Zakim> arve should no longer be muted
15:21:59 <ArtB> ACTION: barstow find someone to help drive the View Modes Media Feature spec to LC
15:21:59 <trackbot> Created ACTION-497 - Find someone to help drive the View Modes Media Feature spec to LC [on Arthur Barstow - due 2010-03-04].
15:22:26 <ArtB> Arve: I can look inside
15:22:30 <ArtB> AB: I'll do the same
15:22:36 <darobin> RobinCopter
15:22:44 <ArtB> Topic: AOB & Announcements
15:22:49 <ArtB> AB: any short announcements for today?
15:23:12 <ArtB> RB: I sent the URI scheme registration request
15:23:18 <ArtB> AB: yes, saw that; thanks!
15:23:38 <ArtB> AB: next call is March 4; no call on March 11; meeting adjourned
15:23:58 <Zakim> -Art_Barstow
15:24:01 <Zakim> -[IPcaller]
15:24:04 <Zakim> -arve
15:24:05 <Zakim> -fjh
15:24:07 <Zakim> -Bryan_Sullivan
15:24:09 <darobin> we should have a Mr Barstow song
15:24:30 <Zakim> -Marcos
15:24:31 <Zakim> IA_WebApps(Widgets)9:00AM has ended
15:24:33 <Zakim> Attendees were Art_Barstow, arve, fjh, Marcos, aphillip, Richard, [IPcaller], felix, Bryan_Sullivan, Steven
15:24:39 <arve> arve has left #wam
15:25:58 <ArtB> RRSAgent, make minutes
15:25:58 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/25-wam-minutes.html ArtB
15:28:54 <ArtB> zakim, bye
15:28:54 <Zakim> Zakim has left #wam
15:30:53 <ArtB> RRSAgent, bye
15:30:53 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2010/02/25-wam-actions.rdf :
15:30:53 <RRSAgent> ACTION: barstow find someone to help drive the View Modes Media Feature spec to LC [1]
15:30:53 <RRSAgent>   recorded in http://www.w3.org/2010/02/25-wam-irc#T15-21-59