[07:40:52] --- fred has joined
[07:41:38] --- fred has left
[07:49:42] --- brtech has joined
[07:52:45] --- ob has joined
[07:53:55] --- Jack3010 has joined
[07:54:00] --- Jack3010 has left
[07:59:03] --- fred has joined
[08:02:46] --- isudo has joined
[08:02:51] --- dashi has joined
[08:02:51] --- mlepinski has joined
[08:03:25] <brtech> I am the jabber scribe. If you have any questiions or comments, I would be happy to relay them to the mike
[08:03:53] <brtech> Agenda bash has occured
[08:04:12] <brtech> New charter is accepted
[08:04:25] <brtech> MSRP drafts have been approved !!!!!
[08:05:21] <brtech> Adv msging requirements drafts has expired, should we revive it or let it die?
[08:05:35] --- csh has joined
[08:05:40] <brtech> hgh: would that be impacted by the discussion of new work
[08:05:49] <brtech> chair: we'll wait
[08:06:31] <brtech> xcap-diff understand the rqmts, work will progress
[08:06:48] --- alexis has joined
[08:06:52] <brtech> Milestone review in progress
[08:07:08] --- nils has joined
[08:09:44] <brtech> aa: if SIMPLE concludes, what happens to further work
[08:09:52] <brtech> chair: ADs will decide
[08:10:24] <brtech> IMDN has a bug in mechanics of extending message/cpim
[08:10:40] --- ben has joined
[08:10:47] <brtech> text changes have been made, submit, don't rerun last call
[08:12:00] <brtech> draft stafford simple dmdn 00
[08:12:09] <brtech> Jerry Shih
[08:12:46] <brtech> This relates to OMA SIMPLE
[08:14:18] <brtech> OMA has pager, one large message MSRP and session
[08:15:43] <brtech> Message Delivery Notification - wants IMDN for session mode for consistent user experience
[08:17:10] <brtech> <slide of call flow for single large message>
[08:17:44] <brtech> wants read notification after 200 OK ending session
[08:18:09] <brtech> hs: 200 OK means everything is okay, you get an error if it didn't work
[08:18:16] --- ysuzuki has joined
[08:18:50] <brtech> hs: how does user know when the message is read?
[08:19:08] --- frodek has joined
[08:19:19] <brtech> js: like sm, sender requests notification
[08:19:48] <brtech> chair: confusion on "read notification" should be "delivered"
[08:20:01] <brtech> hs: delivered and deleted is not the same as read
[08:21:46] --- ttfr has joined
[08:22:17] <brtech> hs: still hung up on "read" vs recieved
[08:22:58] <brtech> bc: how many have turned reciepts off on email? (many in room)
[08:23:31] <brtech> hgs: if we client side filtering we could delete it automatically
[08:25:43] <brtech> dw: some users (stock brokers for example) require delivery confirmation
[08:26:05] <brtech> hs: i delete spam, are they delivered or deleted
[08:26:38] <brtech> am: IMDN spec is about to be published, it has delivery notifications, is it broken
[08:26:48] <brtech> as: SMS has delivery confirmation
[08:27:12] --- bhoeneis has joined
[08:27:53] --- dashi has left
[08:28:23] <brtech> ??: Is this a complaint about IMDN
[08:28:25] --- hbaosiy has joined
[08:28:34] <brtech> br: call a hum on it
[08:28:59] <brtech> chair: there is confusion on "read" vs "delivery" lets not do that now
[08:30:16] <brtech> need confirmation for deferred messaging
[08:30:37] --- Jack3010 has joined
[08:31:27] <brtech> IMDN+MSRP not explored because of complex issues, like message path after session ends
[08:31:36] <brtech> Need more use cases
[08:33:24] <brtech> MG: see some value in use case (esp store and forward)
[08:33:52] <brtech> MG: Could do defer in originating UA, which would change the requirements
[08:34:12] <brtech> JS: Open for any solution
[08:35:01] <brtech> HS: Add to security session issue of using this to collect valid IM addrresses
[08:35:22] <brtech> KS: Have you looked into delivery delayed notiifcations?
[08:35:27] <brtech> JS: no
[08:36:29] <brtech> DW: OMA defined a store and forward mechanism above the IETF protocols. Delivery notification has to be solved up there, not in the IETF protocols
[08:37:17] <brtech> BC: IMDN designed to be a multiprotocl solution (not SIMPLE limited, it's a CPIM thing)
[08:37:34] <brtech> BC: you found out its a valid phone number on the 200 OK
[08:37:43] <brtech> BC: There will be other real security problems
[08:38:10] <brtech> BC: speaking for adam, we need requirements not mechanisms, and there are security requirements
[08:38:35] <brtech> SigComp for SIMPLE
[08:38:52] <brtech> SigComp uses static directories
[08:39:06] <brtech> 3485 doesn't really work on XML
[08:39:24] <brtech> Idea: add a presence specific dictionary
[08:39:39] <ben> correction on last entry: adam stated that this was a reqs doc vs a mechanism doc as a rebuttal to my comments about security. I further rebutted that even requirements can have security issues.
[08:39:49] <brtech> you get another 10% compression
[08:41:16] <brtech> went through all the relevant SIMPLE docs, made a dictionary
[08:42:11] <brtech> HAve to remove short words
[08:42:34] <brtech> Need priorities reviewed
[08:42:34] --- hbaosiy has left
[08:43:59] <brtech> Other than that, believed to be complete
[08:44:08] <brtech> Chair: who will review
[08:44:20] <brtech> <2 or 3 hands>
[08:44:28] <brtech> Does this need to be a WG item?
[08:45:04] <brtech> JP: Needs other reviewers other than the AD, I'll take it through as an individual, AD Shephered
[08:45:25] <brtech> Vehicle Info Event Package
[08:45:45] --- hbaosiy has joined
[08:46:15] <brtech> Example of a larger problem - other vehicles could be covered
[08:46:44] --- hbaosiy has left
[08:46:58] <brtech> How do we deal with events that are not related to communications?
[08:47:47] --- mlepinski has left
[08:48:05] <brtech> that is, not related to a sip session
[08:48:46] <brtech> Need somke kind of a protocol
[08:49:44] --- mlepinski has joined
[08:50:34] --- hbaosiy has joined
[08:52:36] --- hbaosiy has left
[08:52:47] <brtech> BR: Lots of other reasons to have this kind of thing, and there are other "pieces" but no protocol
[08:53:20] <brtech> AR: There was specific guidance to NOT use 3265 for a generalized event notification
[08:53:44] <brtech> AR: Will we have the same problem?
[08:54:05] <brtech> MG: Put drafts into sipping which have some concepts
[08:54:44] <brtech> AH: In favor of expanding, not sure of venue
[08:55:52] <brtech> One thing that came up in this work, Group Membership
[08:56:21] <brtech> MG: our draft talks about "Communities"
[08:56:29] <brtech> Need some guidance
[08:57:34] --- hbaosiy has joined
[08:59:32] <brtech> JP: RAI is limited to interpersonal real time communications
[08:59:51] <brtech> Will set up a mailing list for this discussion
[09:00:14] <brtech> simple-interdomain-scaling-analysis
[09:00:38] <brtech> Chair: Some text in this doc presently is not analysis, that text will be removed
[09:01:26] <brtech> This draft follows from rang-simple-problem-statement-01
[09:02:13] <brtech> Load Modeling depends on user behavior, rush hour, number of devices, etc
[09:02:35] <brtech> draft tries to use conservative assumptions, but still points to a scaleability issue
[09:03:45] <brtech> Can go to 1/2G per sec between domains for consumer domains
[09:04:16] <brtech> The assumptions of 3 changes per hour is thoright to be too low by many
[09:05:17] <brtech> Planned changes to add rush hour, multiple devices, hopefully get real data
[09:07:32] <brtech> BR: Real data would be very helpful to determine the scale of the problem. Data is NOT protocol dependent
[09:07:56] <brtech> HG: Working on it. Easy to make scary numbers bigger. What is the point?
[09:08:46] <brtech> BC: Compare against models, did that, sent some data
[09:10:55] <brtech> Bandwidth Optimizations: Filtering, partial notify, etc mechanisms in development, but create server load
[09:11:06] --- hbaosiy has left
[09:12:06] <brtech> Notify optimization: subnot-etags, others, common notify for multiple watchers, aggregation of notify
[09:14:34] <brtech> Lazy Subscriptions: timed presence, on-demand
[09:16:04] <brtech> AR: 2 kinds of optimizations: things that have been done, things that could be done. The latter need requirements
[09:16:51] <brtech> HS: 3rd cat - things you could do without protocol work (policy, implementation)
[09:17:45] --- hbaosiy has joined
[09:18:21] <brtech> What to do - other than new rev
[09:19:02] <brtech> MSRP Chat
[09:19:23] <brtech> Bouncing between SIMPLE and XCON
[09:20:56] <brtech> Use conf stuff+MSRP same level of functionality as IRC/XMPP/Jabber
[09:22:39] --- bpenfield has joined
[09:23:08] <brtech> Conf focus for signaling, Mixer for text
[09:23:44] <brtech> SDP Negotiation, Nickname handling, Regular Messaging, Private Messaging but not side bars
[09:25:16] <brtech> also not controls and roles/policies
[09:25:35] <brtech> BR: why are nicknames tied to chat, they aren't in other systems
[09:26:17] <brtech> MG: We need it now in chat
[09:26:40] <brtech> MB: Every form of conference needs nicknames
[09:26:52] --- akiniemi has joined
[09:27:20] <brtech> AR: Agreement reached on this subject: everything here can be generalized to all conferencing
[09:28:17] <brtech> AR: This is an expidited way to get chat out, we will do the same thing everywhere
[09:28:42] --- notes-dude has joined
[09:29:02] <brtech> DW: XMPP does it this way (enter a chat room, ask for a "handle")
[09:29:25] <notes-dude> see. I'm dwillis@jabber.org, but known as notes-dude in this chat room.
[09:29:36] --- JeffH has joined
[09:29:55] --- thomas.stach has joined
[09:30:11] <brtech> BC: Addressing Adam's point, if we generalize nicknames, do we have to go back and pull this one out
[09:30:26] --- hbaosiy has left
[09:30:57] <brtech> AN: Code comes out all the time
[09:31:06] <brtech> BC: Features do not
[09:31:24] <brtech> AN: XCON is protocol agnostic
[09:31:41] <brtech> MB: we'll have a protocol agnostic version of this
[09:32:41] <brtech> Joiniing a conference: Send INVITE with message/cpim
[09:33:06] <brtech> new media level chatroom attribute in SDP
[09:34:14] <brtech> Nickname is combination of display name and a SIP URI, not unique to chat room
[09:35:57] <brtech> Example "Alice" <sip:alice%40wonderland@chats.example.com>
[09:36:09] <brtech> New MSRP method NICKNAME
[09:36:27] <brtech> New headers Set-Nickname and Proposed-Nickname
[09:36:38] <brtech> Can get 423
[09:36:53] <brtech> Valid for duratio of session
[09:37:11] <brtech> Advertised through conf event pkg
[09:38:29] --- akiniemi has left
[09:38:48] --- akiniemi has joined
[09:40:41] <brtech> <lots of commentors> should be in SIP, not media
[09:41:22] --- mm has joined
[09:41:55] <brtech> Chair: Please document the reason for why its in the media
[09:42:32] <brtech> Sender wraps message in CPIM with To header to chatroom URI, From could be nickname URI
[09:42:42] <brtech> Send in SEND request
[09:43:25] <brtech> Sending private: wrap in CPIM, send to recipients URI (could be nickname URI)
[09:44:55] --- Nacho.Mas has joined
[09:45:41] --- Nacho.Mas has left
[09:46:36] <brtech> Chair: Humm for accepting as a working group item
[09:46:48] <brtech> <Consensus for accepting>
[09:47:14] <brtech> Report On XCON using MSRP
[09:48:04] <brtech> There is a notion of XCON with MSRP as the media type
[09:49:06] <brtech> Framework pretty much done Conference Object, Cloning Tree model
[09:49:41] <brtech> Complements the niemi draft
[09:49:49] <brtech> nickname not discussed
[09:50:31] <brtech> Should we generalize nicknames
[09:51:38] <brtech> S, belief that XCON compliments chat-room, docs can progress simultaneously
[09:52:10] <brtech> draft-niemi-simple-ice-00
[09:52:45] <brtech> Alternative rendevous mechanism from MSRP Relay
[09:52:57] <brtech> Backwards compatible with plain MSRP
[09:53:55] <brtech> Motivated by lack of support for generic nat traversal mechanism
[09:54:11] <brtech> No possibility to route optimize
[09:54:25] <brtech> lack of real e2e security
[09:54:49] <brtech> Needed tools becoming available (ICE done, ICE-tcp maturing)
[09:55:23] <brtech> Open Issues
[09:55:50] <brtech> ICE-tcp suggests using COMEDIA, proposal to not do that
[09:56:28] <brtech> MSRP requires To-Path and From-Path in SEND, can we drop them? Proposal yes drop
[09:56:59] <brtech> Use RFC4571 framing? Why? Proposal, don't use unless strictly needed
[09:58:41] <brtech> BC: Need From/To Path if you other end doesn't use ICE
[09:58:53] <brtech> AN: It's easy
[09:59:23] <brtech> AR: Hesitant to do radical change in protocol behavior just because of ICE
[10:00:00] <brtech> RS: agree, may need more than one stream down the session
[10:00:15] <brtech> HC: Big change, actually like it, but it's too big
[10:00:54] <brtech> AN: If you put them in WHAT do you put in?
[10:01:01] --- ob has left
[10:01:02] <brtech> HC: Some kind of cookie
[10:03:12] --- Jack3010 has left
[10:04:39] --- thomas.stach has left
[10:04:50] --- nils has left
[10:04:50] --- JeffH has left: Logged out
[10:04:57] --- ttfr has left
[10:05:05] --- ysuzuki has left
[10:05:30] --- isudo has left
[10:05:31] --- notes-dude has left
[10:06:34] --- akiniemi has left
[10:06:38] --- mm has left
[10:07:59] --- isudo has joined
[10:08:02] --- bhoeneis has left
[10:08:07] --- fred has left
[10:09:08] --- bpenfield has left
[10:10:49] --- ben has left
[10:12:19] --- csh has left
[10:13:59] --- isudo has left
[10:14:39] --- brtech has left: Replaced by new connection
[10:15:32] --- mm has joined
[10:15:35] --- alexis has left
[10:15:48] --- mm has left
[10:16:01] --- frodek has left: Replaced by new connection
[10:18:25] --- mlepinski has left
[10:23:28] --- thomas.stach has joined
[10:25:43] --- thomas.stach has left
[10:50:00] --- thomas.stach has joined
[10:50:08] --- thomas.stach has left
[12:10:26] --- m_ersue has joined
[12:40:30] --- m_ersue has left