json - Friday, March 7, 2014

json

json@jabber.ietf.org

Friday, March 7, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[04:54:54] josephyee joins the room
[04:55:33] josephyee leaves the room
[07:46:30] ilari.liusvaara joins the room
[11:24:01] Paul Hoffman joins the room
[11:26:37] Tim Bray joins the room
[11:26:45] <Tim Bray> Is this thing on?
[11:27:01] <Paul Hoffman> It is, as a matter of fact.
[11:27:30] <Paul Hoffman> I'm dropping off, but I'll make sure there is a Jabber scribe for today
[11:27:34] Paul Hoffman leaves the room
[11:27:39] <Tim Bray> I won’t try to take an active part or anything but will be here in case someone wants anything specirfically from me
[11:36:12] Paul Hoffman joins the room
[11:36:47] <Paul Hoffman> i'm not going to be on here, I think. Don't know yet.
[11:44:45] john.levine joins the room
[11:45:18] <john.levine> I'm the scribe. As usual, please use MIC: if you want me to say something for you
[11:49:47] john.levine leaves the room
[11:50:05] <Tim Bray> OK, thanks
[11:50:21] john.levine joins the room
[11:53:01] m&m joins the room
[11:53:30] Barry Leiba joins the room
[11:54:55] Dan York joins the room
[11:55:13] <john.levine> can remote people hear Pete?
[11:55:58] <Tim Bray> we’re supposed to be able to hear?
[11:56:30] Tony Hansen joins the room
[11:56:41] <john.levine> just wondering
[11:56:53] <Barry Leiba> Optional, but helpful.
[11:57:01] <Tim Bray> json not listed at http://ietf89.conf.meetecho.com/
[11:57:14] hildjj joins the room
[11:57:15] <Barry Leiba> I'm in CORE, being responsible AD, and would appreciate brief notes in this jabber room that I can follow.
[11:57:20] <john.levine> ok
[11:57:26] <john.levine> agenda bashing now
[11:57:28] <Tim Bray> what room you in?
[11:57:43] <Barry Leiba> JSON is in Balmoral.
[11:57:47] <john.levine> Balmoral
[11:57:52] <john.levine> now starting I-JSON
[11:58:31] <Tim Bray> hah, yes, I can hear
[11:58:57] resnick joins the room
[12:02:10] <Tim Bray> Matt can emulate me any time
[12:05:46] Dan York leaves the room
[12:06:34] <Tim Bray> MIC: Not expected to be there, just an optional useful thing (maybe)
[12:06:44] <Tim Bray> +1, just reserve it
[12:06:54] john.levine leaves the room
[12:08:28] john.levine joins the room
[12:08:41] <john.levine> sorry, what's the MIC: in ref to?
[12:08:55] <Tim Bray> oh, a couple minutes ago, no biggie just a detail
[12:08:58] <john.levine> ok
[12:09:11] <john.levine> bleeping computer lost its wifi
[12:09:16] <resnick> There's a significant sound delay. Context is important.
[12:09:26] <Tim Bray> ah, OK, thanks
[12:09:50] <Tim Bray> I can hear Joe
[12:11:03] <john.levine> discussion of whether to have a separate media type for i-json profile
[12:11:18] <Tim Bray> Thanks John, I can hear quite well, so don’t bother with the narrative
[12:11:32] <Tim Bray> who’s that?
[12:11:34] <Barry Leiba> The narrative will help me.
[12:11:40] <Tony Hansen> /Tim you're not the only one watching jabber
[12:11:44] <Tim Bray> k
[12:11:50] <Tim Bray> who’s talking?
[12:11:58] <john.levine> Joe Hildebrand
[12:12:17] <resnick> (with understood time delay.
[12:12:35] <john.levine> Larry Masinter
[12:13:44] <resnick> Dave Cottlehuber coming up
[12:14:24] <Tim Bray> what's the problem?
[12:14:26] <john.levine> we have three dead mikes now
[12:14:29] <john.levine> and one live one
[12:14:30] <Tim Bray> heh
[12:14:43] <resnick> mics. Dead Mikes would be much more of a problem.
[12:15:12] <john.levine> you use your stylebook, I'll use mine. humph
[12:16:01] <Tim Bray> since I have audio, I’ll scribe a bit
[12:16:21] <Tim Bray> CouchDB guy says: for my database app, I’d like to accept any busted JSON and emit I-JSON
[12:16:47] <Tim Bray> Hegaret, W3C: Don’t expect support from browsers. If not supported by browsers, not useful
[12:17:13] <Tim Bray> Hildebrand: There are so many more browsers in JSON that aren’t in browsers. No users, no user-agent, no browser, nobody from a browser vendor has written a line of code.
[12:17:57] <Tim Bray> Hildebrand: The intent is that I’d rather have this fail than be processed in the lackadaisical way it is today
[12:19:02] <Tim Bray> Tony Hansen: example of a place where a profile has different effects on the protocol is a profile of SMTP, different port, different hoops to jump through.
[12:19:12] <Tim Bray> Hansen: In favor of a different media type
[12:19:20] <hildjj> Tim: feel free to add whatever you like to the conversation as well.
[12:19:33] <Tim Bray> I’ll say MIC: if I want to speak up
[12:19:42] <Tim Bray> Mnot: Is lukewarm at best about the media type and process
[12:20:12] <Tim Bray> Mnot: Consistently, is not a fan of application/json - he wants protocol-specific media types
[12:20:23] <Tim Bray> Mnot: Don’t mint a media type.
[12:20:56] <Tim Bray> Mnot: Wants to talk about reserved key value top-level thing. He’s very unhappy with it, would get persisted if JSON <=> I-JSON converted, which seems bad. So he’s strongly against it.
[12:21:20] <Tim Bray> Masinter: Profiles are great. Hasn’t heard a use case for a new media type.
[12:21:58] <Tim Bray> There's HTML & HTML5, but no new media type because it’s a subset
[12:22:39] <Tim Bray> Le Hegaret: W3C WG working on a proposal to submit JSON from HTML forms, but no contemplation of a new media type
[12:23:14] <Tim Bray> Tony Hansen: Further discussion of HTML/HTML5, notes that new DOCTYPE is comparable to reserved-I-JSON-key
[12:23:37] <Tim Bray> Hansen: And this places the onus on the receiver to process in a very restrictive manner.
[12:24:21] <hildjj> I think what some are arguing is that you specify i-json processing in your REST API doc.
[12:24:49] <Tim Bray> Q from someone for mnot: If I don’t have a specific media type, how does a RESTful app negotiate with a server?
[12:24:57] <hildjj> and that the client can then safely call JSON.iparse() instead of JSON.parse()
[12:25:19] <Tim Bray> Mnot: <sorry, lost his thread>
[12:26:03] <Tim Bray> MIC: My expectation is that the JOSE/JW* community would start specifying I-JSON and pester library builders to implement parser modes to report violations of I-JSON
[12:26:16] <Tim Bray> Mnot: Doesn’t like media type, really hates reserved key
[12:26:57] <Tim Bray> CouchDB guy: Would require his clients to understand CouchDB I-JSON as opposed to Mongo I-JSON, doesn’t feel good
[12:27:10] hildjj leaves the room
[12:27:28] Joe Hildebrand joins the room
[12:27:32] <Joe Hildebrand> tim, you're after me in  line, and i'll relay
[12:27:59] <Tim Bray> Mnot: This is exposing the weakness of the whole proposal. Suppose I have a Web Service and specify I-JSON.  Presupposes that my clients will go find/use the right library.
[12:28:41] <Tim Bray> MIC: Currently, people doing the crypto/identity protocols explicitly specify no dupe keys, etc.  The objective is to allow them to just say I-JSON and covr all the bases
[12:28:49] <Joe Hildebrand> ack
[12:29:11] <Tim Bray> Resnick: If I’ve implemented a JSON reader I can consume I-JSON, but telling me it’s I-JSON doesn’t help me.
[12:29:43] <Tim Bray> Resnick: Can’t figure out what circumstance a sender wouldn’t want a receiver to consume if problems
[12:30:04] <Joe Hildebrand> i said "security" behind him
[12:30:05] <Tim Bray> MIC: Because multiple dupe keys can be used as a crypto exploit. They frighten JOSE types
[12:30:11] <Joe Hildebrand> ack
[12:30:34] <Tim Bray> Resnick: Since extra parameters are ignored, e.g. in email, maybe there’s another way to do this.
[12:31:07] <Tim Bray> Resnick: Feels like application/json and app/*+json are good, and using something else to signal the profile is good.
[12:31:35] lellel joins the room
[12:32:34] <Tim Bray> Hildebrand: Am starting to think that if I'm documenting my REST API, I could decide to say “I guarantee I'll always send me I-JSON, and I will fail if you don’t send me I-JSON.”
[12:32:41] <Tim Bray> 400 to be precise
[12:33:16] <Tim Bray> Hildebrand: Assumes that clients will call JSON.i_parse instead of JSON.parse
[12:34:43] <Tim Bray> Hoffman: None of that needs a new media-type
[12:34:51] Tony Hansen leaves the room
[12:34:57] Tony Hansen joins the room
[12:35:07] <Joe Hildebrand> Tim: adequate?
[12:35:09] <Tim Bray> Bray: See MIC above. Thanks JOe
[12:35:26] <Tim Bray> Hoffman: Backs up Bray comment about dupe keys & security issues.
[12:36:49] <Tim Bray> Mnot: A moral hazard exists in defining a new format that’s backward compatible with a popular format, but with dramatic new semantics.  So a developer will look at it & say “oh, just JSON”, so there’s a moral hazard when you get a surprise at new semantics.
[12:37:02] <Tim Bray> Mnot: analogy with making HTTP/2 not look like HTTP/1.1 to avoid this kind of failure mode.
[12:37:14] <Tim Bray> Joe: But it *is* JSON
[12:37:37] <Tim Bray> Mnot: But sender is relying on receiver having an error in a certain situation and if receiver doesn’t have I-JSON, that won’t happen. It’s a moral hazard
[12:38:22] <Tim Bray> Joe: More about the JSON being sent back to the server. If on the server I document that my interface is I-JSON, if you send me borked-up JSON, and you’re probably attacking me, then I’m going to reject your request with some specified HTTP error
[12:38:52] <Tim Bray> Joe: When I’m specifying my API, in the REST case, not security-specific, I will specify that I will only send I-JSON, if you get anything else, feel free to fail on it, maybe someone is attacking.
[12:39:07] <Tim Bray> Mark: Feel free to fail, but sender can’t rely on that.
[12:39:27] <Tim Bray> Joe: Likes the rules. Media-type issues not evident.
[12:39:32] <Tim Bray> Joe: Has already bought the pig.
[12:39:37] <Joe Hildebrand> Aside from the security cases.
[12:40:29] <Tim Bray> Missed name: Seems more & more obvious to ask: Do we need at all to go into media-type thing?  Let it be a useful profile for e.g. JOSE to specify, but not something client or server would actualy act on
[12:40:45] <Joe Hildebrand> Dave Cuttlehuber
[12:40:49] <resnick> The question of whether there should be a profile is separate from what sort of labeling there should be.
[12:40:49] <Tim Bray> CouchDB guy (I think): Need a way to negotiate this.  There are definite needs for lcients/servers to have a stricter model, but right now there’s no way to say that.
[12:40:57] <Tim Bray> +1 resnick
[12:41:04] john.levine leaves the room
[12:41:11] <Tony Hansen> it's a quality of implementation issue whether the recipient follows the rules and checks for i-json or doesn't and treats it as json
[12:41:16] <Joe Hildebrand> Cottlehuber
[12:41:18] <Tim Bray> Right now they’re passing around all sorts of rotten shit, would like to stop, but doesn’t need a media type
[12:41:34] <Tim Bray> Miller: Take the comments to the mailing list
[12:41:48] john.levine joins the room
[12:42:05] <Tim Bray> MIC: Worth asking about general sentiment to proceed with I-JSON in recharter?
[12:42:28] <john.levine> sorry, Paul cut the line
[12:42:47] <Tim Bray> Moving on to discussion of syntax/description/nomenclature domain
[12:42:59] <john.levine> now protogen, Phill's proposal presented by Paul H
[12:42:59] <Tim Bray> First: Protogen.
[12:43:06] <Tony Hansen> Paul said to me that charter issues would be dealt with at the end
[12:43:11] <Tim Bray> Hoffman channeling PHB
[12:43:20] <Joe Hildebrand> Tim: I think they want to discuss it more on the list.
[12:43:57] <Joe Hildebrand> Tim: do you have the slides?
[12:44:00] <Tim Bray> Protogen not just for JSON. Run it through a generator and it can generate all sorts of stuff, including xml2rfc, C#, C.
[12:44:08] john.levine leaves the room
[12:44:09] <Tim Bray> I wrote the slides, but I think Paul edited them a bit
[12:44:16] <Joe Hildebrand> i mean for PHB's stuff
[12:44:25] <Tim Bray> Hoffman/PHB: Input language is sort of schema-ish but not really, has other stuff.
[12:44:35] <Tim Bray> I don’t care in the slightest about this stuff, I think it’s a horrible idea.
[12:44:42] <Joe Hildebrand> :)
[12:44:44] <Tim Bray> Generically I mean, schema-like things
[12:44:48] <Joe Hildebrand> nod
[12:45:46] <Tim Bray> MIC: Anything that ventures even slightly into schema territory is actively harmful because it distracts WG from getting the normative English text right.
[12:46:02] <Tim Bray> MIC: Any sane protocol is going to have lots of constraints that can’t be expressed in any schema language.
[12:46:16] <Tim Bray> MIC: Haven’t seen an example of a JSON-based APi where a schema would have improved the specification.
[12:46:22] <Tim Bray> </MIC>
[12:46:42] <Joe Hildebrand> http://en.wikipedia.org/wiki/G%C3%B6del_(programming_language)
[12:46:58] <Tim Bray> <for details on PHB proosal see slides>
[12:47:29] john.levine joins the room
[12:48:04] <Joe Hildebrand> mic: ack
[12:48:11] <Tim Bray> Thanks Joe
[12:48:40] <john.levine> just as well Joe got it, my connectivity stinks
[12:49:22] <Tim Bray> Someone: Doesn’t understand why the input language is different from anything we already have
[12:49:42] <Tim Bray> Why isn’t input ABNF or something? Why do we go there?
[12:50:16] <resnick> The ABNF question was Henrik Levkowitz.
[12:50:24] <resnick> After that was Yoav Nir.
[12:50:26] <Tim Bray> <missed name>: Suppose I want to create a record: Last name, First name, area: I guess I learn this new language and run it through Phil's parser, and what JSON comes out?
[12:50:35] <resnick> Joel Hildebrand answering.
[12:50:43] <m&m> Yoav Nir said that Tim
[12:50:58] <Tim Bray> Joe: I think the code that gets output is code that can parse/generate the JSON that fits the schema more easily than a generic JSON library
[12:51:27] <m&m> feel free to help with minutes at http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-json?useMonospaceFont=true
[12:51:29] <Joe Hildebrand> Matt: you could close the lines on this any time and I think the people in the room would be happy.
[12:51:52] <Tim Bray> Masinter: BCP70 had a long debate over which schema language to use to describe XML vocabularies, and they decided to not tell you which one. So my suggestion is that PHB can continue on this path and we not endorse one.
[12:52:31] <Tim Bray> Andy Newton presenting JSON Content Rules, which is expired:
[12:52:56] <Tim Bray> Not going to talk about solution, but motivation. Things pulled out of mailing-list discussion.
[12:53:00] <m&m> will do
[12:53:26] <Tim Bray> 2 things going on: … sorry, lost thread …
[12:53:56] <Tim Bray> Newton: This direction isn’t where we need to go. Need to think about how to make our docs better in the IETF.  Just worry about our own products.
[12:54:28] <Tim Bray> Newton: Requirements that we might want to make a MUST, don’t want reading/writing to be tedious, want concise/precise.
[12:55:03] <Tim Bray> Newton: Nice to haves are more objective: Does formalism support modularity, can intersperse with prose?
[12:55:17] <Tim Bray> Newton: THere are people who are already doing this, people are already going with one formal notation or another.
[12:56:17] <Tim Bray> Newton: 3 he found. ABNF, Barry came up with Reputon the 2nd, talked about that in Vancouver came up with a bunch of English words to describe content. Finally my own JSON content rules, a little more compact but isomorphic to Barry’s thing
[12:56:48] <Tim Bray> Newton: Bray argues that schema languages are hard to do.
[12:57:07] <Tim Bray> Newton: Not sure, not an expert. But if we’re gonna support tooling etc, it’s a hard road to go down.
[12:57:14] <resnick> Leif Johannsen speaking.
[12:57:30] <Tim Bray> Leif: In favor of schema languages generally. Especially at extension points.
[12:57:56] <Tim Bray> Newtion: Some sort of formal notation OK. But not a full-blown schema language, if we go towards an XSD or ASN.1 like direction.
[12:58:17] <Tim Bray> Newton: Bray argues that the prose is what matters, wouldn’t have interoperability without it.
[12:58:28] <Barry Leiba> Barry agrees with Bray
[12:58:33] <Tim Bray> Newton: So if we have a formal notation, it should support not distract
[12:58:51] <Tim Bray> Newton: I have had a natural-language precision failure myself.
[12:58:51] <Barry Leiba> Barry agrees with Andy.
[12:59:49] <Tim Bray> Bray via Hildebrand: See MIC above
[13:00:31] <Tim Bray> that's all
[13:01:17] <Tim Bray> of course, that happens all the time
[13:01:45] <Tim Bray> Newton: Offers an example of a situation in which two implementers were inconsistent based on prose
[13:02:13] <Joe Hildebrand> Tim: yes.  it's possible to write non-interoperable specifications in many different working groups
[13:02:24] <Tim Bray> Tony Hansen: In Reputon, the ABNF was really hard to read. People get ABNF wrong all the time, people read it wrong, to understand REPUTON you had to step up one level from the bits on the wire and look at the data structure.
[13:02:43] <Tim Bray> Hansen: More useful to think of it at that level.
[13:03:06] <Tim Bray> Hansen: He’s hearing a lot of discussions of different schema languages. CDDL, CBOR, JSON. There has to be synergy between these efforts.
[13:03:23] <Tim Bray> Hansen: A CBOR schema should be very similar to one for JSON.
[13:04:00] <Tim Bray> <unknown>: Consider combo of netconf & yang. Why is that stack so different from app protocols based on JSON?  Why are schemas required in netconf but not in JSON.
[13:04:13] <Tim Bray> (Julian Reschke I think?)
[13:04:16] <john.levine> Leif
[13:04:25] <john.levine> Julian is behind him
[13:04:47] <Tim Bray> Leif: Particularly when it comes to extension points, schemas or DDLs really help with that.
[13:05:30] <Tim Bray> Mnot: Agrees with Bray that schema languages is a direction they should not go in. A set of vocabulary would help, but when you create a schema language there’s a tendency to make higher-level concepts, e.g. XSD and WADL, to make things easier for people
[13:05:57] <Tim Bray> Mnot: When you do that you encourage certain patterns and discourage others. So WG would have pressure to come up with right patterns of use for JSON. Which he thinks is too difficult, probably couldn’t be done
[13:06:20] <Tim Bray> Hoffman: <no hat> Agrees. Barry suggested we don’t specify one, but we catalog them or mention them or some such.
[13:06:52] <Tim Bray> Hoffman: Mnot - how would you react to a last-call doc with some schema or another? Would you read the schema part?
[13:07:08] <Tim Bray> Mnot: If it a working group I cared about using a schema, I’d jump up and down.
[13:07:46] <Tim Bray> Julian: in the slides there was an example of trying to JSON with abnf, this is a bad idea, confusing layers, I think we have consensus that JSON in abnf is a bad idea.
[13:08:08] <Tim Bray> Julian: Formal languages that could be translated to prose, that’s a good idea, not sure if it means a single language but the prose emitted was understandable.
[13:08:25] <Tim Bray> Julian: Would be be nice to have an example of the kind of prose we’d like to see, e.g. the Reputon example.
[13:08:47] <Tim Bray> Julian: In the xml2rfc drafts, we are generating prose from a schema and it’s the prose that’s normative.
[13:09:25] <Tim Bray> Hoffman: Julian has a tool that takes an RNC schema and makes RFC-like language from it.
[13:09:55] <Tim Bray> Justin Richer: My experience as an app/protocol developer, in all my years programming XML & JSON, I have never once liked a schema or found it useful or got any use from it
[13:10:15] <Barry Leiba> Justin: Hear, hear!
[13:10:29] <Tim Bray> Justin: I care about the object model, and how to serialize/deserialize it. One could argue that a schema language is a formalized defn of an object model. Or not. And we don’t have consensus on this.
[13:10:48] <Tim Bray> Justin: Previous example on guys who got it wrong. Having a schema wouldn’t have saved you.
[13:11:15] <Tim Bray> Justin: Developers don’t read either prose or schemas, they read examples. Then maybe the normative text.
[13:11:55] <Tim Bray> <someone>: Schema languages tend ot be created for the benefit of computers.
[13:12:16] <resnick> Yoav Nir.
[13:12:24] <Tim Bray> <somoene>: That's not what developers need. Concentrate on the prose and restrict it, a dialect of English for describing object models.
[13:12:47] <Tim Bray> Nir: e.g. always say “float” when you’re describing one, don’t say “double” or whatever. I can never read ABNF.
[13:13:15] <resnick> ABNF was intended to be a readable formal language. It's success in that is open for debate.
[13:13:20] <Tim Bray> Dave from Couch: We wear two hats. People cut & paste examples. People use libraries, and they need to be written with interop in mind, and that’s where schemas come in handy.
[13:13:31] <Tim Bray> Dave: Can use a schema to generate test suites/parsers etc
[13:13:52] <Tim Bray> Dave: And that’s important, it gives you confidence that you’re complying.
[13:14:33] <Tim Bray> Hoffman: We’re discussing this in the WG with reference to the possible use of schemas in I-Ds and RFCs.
[13:15:07] <Tim Bray> Dave: IETF is about implementation, and for that he thinks a formal grammar is a huge advantage
[13:15:23] <Tim Bray> Dave: Also consider non-native-English speakers.
[13:15:56] <Tim Bray> Lief: Both Mark/Justin gave good arguments. He’s more interested in metamodels than schemas.  And yang/netconf has been wildly successful.
[13:16:08] <Tim Bray> MIC: I think an open-source test harness is way more useful than a schema
[13:16:44] <john.levine> ok
[13:16:45] <Tim Bray> Tony Hansen: When I’m writing an RFC using xml2rfc and I get a strange message saying “you messed up” I go to the schema to figure what I was supposed to do
[13:17:04] <Tim Bray> Tony Hansen: Schema told both me & xml2rfc parser what to do.
[13:17:51] <Tim Bray> Hansin: Recently implemented all the SCRAM/SASL specs, and on several occasions people on the team came back and with hash problems, he asked if they looked at the ABNF and they said “what’s that?” and he asked them how they could do anything without ABNF
[13:18:12] <john.levine> oure next
[13:18:16] <Tim Bray> Chris Newman: Schema languages constrain the solution space. This always happens. ABNF, for a string of a bytes is great, if tagged properties terrible.
[13:18:18] <john.levine> you're
[13:18:19] <Tony Hansen> … without >>understanding<<< the ABNF
[13:19:02] <Tim Bray> Newman: Purpose of RFCs is to promote ineteroperability, helping implementers is secondary. If the schema lang will help interop that’s good, e.g. ABNF does this. It sets clear rules, is not ambiguous.
[13:19:20] <Tim Bray> Newman: First thing I do is read & implement to the ABNF.
[13:19:31] <Joe Hildebrand> Tim, i missed your mic but have it now.
[13:19:43] <Joe Hildebrand> nm, john has it.
[13:19:47] <Tim Bray> Newman: A schema can in fact promote interoperability.
[13:19:48] Barry Leiba leaves the room
[13:20:35] <Tim Bray> oops, Meetecho shut down at scheduled end of meeting
[13:20:40] <Tim Bray> Gotta go get my airplane.
[13:20:42] <Tim Bray> thanks everyone!
[13:20:46] <john.levine> we're basically done
[13:20:55] <john.levine> mark is last at mic
[13:21:16] <Tim Bray> wouldn’t mind a tl;dr on what mnot says
[13:21:55] <john.levine> mnot still doesn't like schma languages
[13:22:11] <john.levine> hoffman: will take to list to figure out what's actionable
[13:22:50] <john.levine> resnick: reporting on OMA liason statement
[13:22:57] <john.levine> they want a scheme
[13:22:59] <john.levine> schema
[13:23:14] <Tim Bray> OMA?
[13:23:19] <Tim Bray> whatever, later, thanks again
[13:23:20] Tim Bray leaves the room
[13:25:52] Dan York joins the room
[13:26:08] <Joe Hildebrand> Open Mobile Alliance
[13:26:11] lellel leaves the room
[13:27:37] john.levine leaves the room
[13:27:41] Joe Hildebrand leaves the room
[13:27:51] Paul Hoffman leaves the room
[13:28:44] resnick leaves the room
[13:29:05] m&m leaves the room
[13:31:08] Tony Hansen leaves the room
[13:51:10] Joe Hildebrand joins the room
[13:52:33] Dan York leaves the room
[14:03:41] Tony Hansen joins the room
[14:08:16] Joe Hildebrand leaves the room
[14:56:57] Tony Hansen leaves the room
[15:00:38] josephyee joins the room
[16:00:13] m&m joins the room
[16:15:22] josephyee leaves the room
[16:33:15] m&m leaves the room
[16:33:48] m&m joins the room
[16:36:18] Paul Hoffman joins the room
[16:56:59] josephyee joins the room
[17:29:14] Paul Hoffman leaves the room
[17:36:39] ilari.liusvaara leaves the room: offline
[17:43:37] m&m leaves the room
[23:26:08] josephyee leaves the room