lemonade@conference.ietf.jabber.com - 2003/03/20

[08:45] %% logger has arrived.
[16:38] %% rjs3 has arrived.
[16:45] %% leg has arrived.
[16:47] %% wcw has arrived.
[16:51] %% hildjj has arrived.
[16:51] %% lisaDusseault has arrived.
[16:53] <leg> i already took minutes once this ietf
[16:53] %% mrose has arrived.
[16:53] %% hardie has arrived.
[16:54] <rjs3> you are in the room though, I'm guessing
[16:54] * hardie has set the topic to: Charter & Status
[16:55] %% avshalom has arrived.
[16:55] %% nsb has arrived.
[16:55] * hildjj has changed the subject to: Charter and Status
[16:55] <hildjj> &'s may be bad karma for some.... :)
[17:00] <hildjj> anyone have a pointer to the agenda?
[17:04] <mrose> i can't find it... let me see if i can post it.
[17:06] <mrose> Date: THURSDAY, March 20, 2003
Time: 1530-1730 Afternoon Sessions II
Location: Imperial A
Directorate: APP
Abbreviation: lemonade
Title: License to Enhance Messaging Oriented Network Access for Diverse Endpoints PWG


Note Wells & Agenda Bashing :05

Requirements (Kue Wong) :20
http://www.ietf.org/internet-drafts/draft-wong-umcli-02.txt

Server-to-Server Requirements (Lisa Dusseault) :20
http://www.ietf.org/internet-drafts/draft-dusseault-s2s-event-reqs-00.txt

SNAP (Ari Erev) :20
http://www.ietf.org/internet-drafts/draft-shapira-snap-05.txt

Next Steps and Document Assignments (Chairs) :20

Mobile Messaging Invited Discussion (Alan Stebbens & Milt Roselinsky) :30
* There is a document for this presentation on the mail list.
* The web interface is broken right now. I'll post the link by Monday evening.
-
[17:07] <hildjj> and the mailing list?
[17:08] <leg> don't we already believe this if we're here? do we have to be sold to?
[17:08] <mrose> hildjj - http://flyingfox.snowshore.com/um_archive/maillist.html
[17:08] <leg> mailing list is mailto:um@snowshore.com
[17:09] %% dcrocker has arrived.
[17:09] <nsb> Actually, leg, there are probably people in the room who don't know any of this and are here to learn.
[17:09] <mrose> nsb - quick, let's paint a scarlet N on their sleeves
[17:11] <dcrocker> ietf meetings are not for tutorials. they are for development.
[17:11] <mrose> don't get pete started...
[17:11] <nsb> Reality is reality, though. There are a lot of newbies here.
[17:11] %% eburger has arrived.
[17:11] * mrose has changed the subject to: wirelss issues
[17:12] <leg> i have no problem with explanations & helping people to learn. i'm not sure i love "rah rah what we're doing is great".
[17:12] %% resnick has arrived.
[17:12] <mrose> hey! no chairs allowed (just kidding)
[17:12] <dcrocker> it is reasonable to do a level-set tutorial at the beginning of the group's effort. after that, we are constantly faced with having new people present. if we always spend time training them, we get no real work done.
[17:13] <resnick> Pete is about ready to "get started" in 1 minute.
[17:13] <mrose> let's take this to another chatroom, ok?
[17:13] <mrose> i'd rather focus/comment on what he's saying
[17:13] <eburger> Slides for the session are at http://flyingfox.snowshore.com/i-d/lemonade/slides56/index.html
[17:13] <eburger> BTW, we'll give him 3 more minutes...
[17:14] <nsb> I am now convinced. I will never let my students use jabber while I'm lecturing.
[17:15] %% randy has arrived.
[17:15] <hildjj> nsb: you'll need a wifi jabber
[17:15] <hildjj> s/jabber/jammer
[17:15] <hildjj> (boy, that was freudian...)
[17:15] <nsb> I can just ban computers from my classes, increasing number of profs are doing that.
[17:15] <nsb> Of course there are those pesky mobile devices...
[17:16] <leg> don't worry, next year they'll tape your lectures and you'll never have to see students again.
[17:16] <hildjj> wasn't that a scene in "Real Genius"?
[17:16] <leg> after all, it's not like you're in a field that ever changes.
[17:17] <nsb> Will I still get paid?
[17:17] %% danwing has arrived.
[17:17] <leg> probably. this talk is making me think of IBM's "universal business adapter" commercial---we'll convert any format into the right format.
[17:18] <resnick> (marketing guys with mumbo-jumbo......hmmm.....what does that remind me of?)
[17:28] <resnick> I'll jabber for a bit.
[17:29] <resnick> Lisa Dusseault on server-to-server issues
[17:30] <hardie> Lisa Dusseault snaps back!
[17:30] <resnick> Notification proposal is on the table (e.g. SNAP)
[17:31] <resnick> There's lots of notify work
[17:31] <resnick> Calendering, SIP, HTTP/WebDave, etc.
[17:31] <resnick> XMPP, Email, News, Voice ("unified") messaging
[17:31] <hildjj> resnick: is that WebDave Crocker?
[17:32] <hardie> No, it's "I'm sorry DAV, I can't do that..."
[17:32] <resnick> Ahem.
[17:32] <resnick> (*Pause for technical difficulties.....please stand by*)
[17:33] <leg> is there an engineer in the house?
[17:33] <resnick> One model: notification aggregator
[17:34] <resnick> Everybody sends to one server who sends to the client.
[17:34] <resnick> manages subscriptions and gateways
[17:35] <resnick> the aggregator can route to the appropriate place with multiple clients
[17:35] <resnick> What to do? ID problems, see if we can easily solve, keep architecture in mind
[17:35] <resnick> Model
[17:35] <resnick> resource generates events
[17:36] <resnick> (use URI for universality)
[17:36] <resnick> Event Types depend on the resource type.
[17:37] <resnick> extensible, maybe app types, subtypes
[17:37] <dcrocker> i'm confused again. i thought the 'requirement' was for invoking a notification subsystem that a message is now available. she's talking about a big, separate effort, ti seems.
[17:37] <resnick> subscriber requests events based on resource and type
[17:37] <resnick> Discovery Problems
[17:37] %% akstebbens has arrived.
[17:37] <resnick> user: "I want to subscribe"
[17:38] <eburger> Lisa's slides are at http://flyingfox.snowshore.com/i-d/lemonade/slides56/notification-architecture.ppt
[17:38] <leg> the requirement is for server to server notifications. she is trying to describe what those notifications look like.
[17:39] <resnick> I think she said at the beginning that she's talking about the bigger picture architecture, of which our requirement is a subtype.
[17:39] <leg> the hope is that the server to server solution isn't going to be so specific that it makes it hard to do anything else.
[17:40] <dcrocker> leg, she is going far beyond that. she is going into a) lots of other participants, and b) all sorts of end-user client option stuff.
[17:40] <akstebbens> why are we worrying about IM notifications here, when the IM protocols are still "under construction"?
[17:40] <dcrocker> in other words, we don't need no stinkin' aggregator, for this working group.
[17:41] <leg> the receiver of these messages is the "aggregator". it is a gateway into a proprietary world that aggregates notifications using IETF protocols.
[17:42] <resnick> She's now talking about searching for what you want notifications on.
[17:42] <dcrocker> i'm sorry, but her presentation is simply irrelevant to this working group.
[17:42] <leg> the discovery stuff is stuff that this WG ain't going to solve.
[17:42] <akstebbens> so creating a protocol to support "gateway" technology reinforces the continued use of the gateway technology, instead of a end-to-end delivery.
[17:43] <eburger> I'm hoping it will get relevant; the s2s paper actually had some good stuff in it.
[17:43] %% mishizue has arrived.
[17:43] <mrose> actually, i think she's explaining the architecture that relates everything
[17:43] <akstebbens> typically, gateways are created to accomodate "legacy" protocols. Shouldn't new protocols be end-to-end, and not be addressing the gateway technology?
[17:44] <dcrocker> marshall, i do not mean that the presentation is not interesting. i think it is dandy stuff. but nearly everything she is talking about is irrelevant to the work of this group.
[17:44] <randy> I don't think the aggregator needs to have anything to do with gateways
[17:44] <mrose> hildjj: so does lemonade boil down to presence+rss?
[17:44] <leg> the charter item for the WG is specifically for server to server notification passing. it's pretty clear that's to help legacy protocols.
[17:45] <randy> Consider a simple case: notification of new mail arrival. We have things like notifymail that have been around for many years
[17:45] <randy> But that (aside from not being published as an RFC) sends notifcation for every new mail arrival
[17:46] <randy> If you have a mobile client, you might only want notifications of "important" or "interesting" mail, or if it's been a while since the last notification
[17:46] <randy> An aggregator can handle these issues
[17:46] <dcrocker> this is why i have lobbied for the charter to simply say that THIS working group will specify a means of invoking a notification subsystem of new mail.
[17:46] <akstebbens> randy, what you are describing is a requirement (feature) for how notifications get generated, not what protocol is used to deliver them.
[17:47] <akstebbens> The issue of filtering is orthogonal to the protocol used for notifications.
[17:47] <randy> The aggregator might sit in the middle, between arbitrary email servers and the handset
[17:47] <akstebbens> great. yet another middle box
[17:48] <leg> the cell phone biz is full of middle boxes.
[17:48] <randy> Well, either you put notification preferences in the various servers, or you put them on something that sits on the edge between the handset and the well-connected world
[17:48] <mrose> hildjj???
[17:48] <randy> If you put them in the servers, no middle box, but also no overall throttle mechanism
[17:48] <randy> I
[17:49] <akstebbens> it's okay to put notification rules in the server, but unless the client must manipulate them using a standard protocol, there is no need for the client to actually understand how to construct the rules.
[17:49] <randy> I'm not personally convinced we need these aggregor boxes, but I see the point of those who do
[17:49] <hildjj> mrose: sorry... i looked away. what?
[17:49] <mrose> hildjj - does lemonade boil down to presence+rss?
[17:50] <randy> Even if you construct the rules in a standard way, such as Sieve, you still have the problem of multiple servers all sending notifications, and you may want to only get in chunks, unless one of them is super important
[17:50] <hildjj> mrose: maybe.
[17:50] <hildjj> or maybe it's a case of pub/sub.
[17:50] <hildjj> http://www.jabber.org/jeps/jep-00060.html for example.
[17:50] <leg> that URL fails for me?
[17:50] <mrose> right
[17:51] <randy> http://www.jabber.org/jeps/jep-00060.html = 404
[17:51] <hildjj> too many zeros.
[17:51] <hildjj> http://www.jabber.org/jeps/jep-0060.html
[17:51] <akstebbens> seems to me that the notification server should be able to proxy its own protocol, in which case it can be used to aggregate multiple notification streams
[17:52] <akstebbens> and, of course, have rules about how to aggregate and at what frequency
[17:52] <randy> That's what I was thinking too. You have a std protocol by which the servers send stuff to the user at the user's address. That addres sis another server that sends them on or not to the user at the handset
[17:52] <akstebbens> in any case, the architecture of notification (multiple, proxying, etc.) is independent of the protocol that delivers notifications
[17:53] <hildjj> akstebbens:yes. at least at the edges of the notifications system's "native" protocol.
[17:53] <leg> i'm almost disappointed in how nice dcrocker was compared to his jabbering.
[17:53] <akstebbens> who is to say that my super-duper-notification server isn't a super-scalable notification server that provides basic service notifications as well as agreggates notifications from other services? This is the same issue as the class EMS system in TMN.
[17:53] <dcrocker> leg, haven't you noticed that flaming in messaging is almost always much worse than in face-to-face?
[17:54] <randy> Alan, makes sense to me
[17:54] <eburger> :eek2
[17:54] <randy> What's 'eek2'?
[17:54] <akstebbens> so.. this WG should focus on the protocol -- keeping it simple, and not expanding scope to solve all problems everywhere.
[17:55] <randy> Of course. And if the protocol can be expanded then the rest of the problems can be solved later without reinventing everuything
[17:55] <hildjj> randy: s/expanded/extended/ ?
[17:55] <akstebbens> stand/I
[17:56] <dcrocker> lisa, don't read the archive.
[17:56] <randy> Yes
[17:56] <lisaDusseault> Of course I must now, Dave!
[17:58] <eburger> http://flyingfox.snowshore.com/um_archive/msg00113.html
[17:58] <akstebbens> randy, back to the basic notification protocol design for notification -- it should be designed for end-to-end : client to server, and not specifically designed to deal with aggregation issues.
[17:59] <randy> Sure
[17:59] <dcrocker> i think that the basic requirement for some sort of global addressing and extensible content/type labeling is fine.
[17:59] <randy> Because such a protocol can be used btwn the aggregator and the end user, as well as between far-field servers and the aggragator
[17:59] <mrose> uh, has anyone in the room read 3205
[18:01] <randy> Yes, but it doesn't go nearly far enough -- it's too mild
[18:01] <akstebbens> yes
[18:01] <mrose> heh, heh...
[18:01] <hardie> Keith would be happy to rewrite to fit your needs....
[18:01] <akstebbens> i liked it, as well as your other doc on the design of protocols. I waved it around in a few 3GPP meetings about a year ago.
[18:01] <lisaDusseault> I must have been giving the impression that I think the whole problem should be taken on. It should not. I was putting up detailed danger signs.
[18:01] <akstebbens> didn't help though :-(
[18:04] <akstebbens> I appreciated the survey but it clouded the issue on what, exactly, was being proposed for design requirements.
[18:04] <lisaDusseault> True. I don't expect the survey is needed ever again but it introduces terminology and concepts that will sink in.
[18:04] <hildjj> errors: http://www.jabber.org/ietf/draft-ietf-xmpp-core-05.html#xmlstreams-error
[18:05] <randy> i sent Keith comments on it some time ago
[18:06] <randy> Lisa, I think your document was great. Your slides implied that you were proposinng a lot of work, whereas your document was much more clear
[18:06] <leg> i think just defining the _form_ of the notification (a new MIME type?) is as hard if not harder than the transport.
[18:06] <randy> Lisa's draft has a number of areas that we need to pay attention to when we do the protocol
[18:07] <hildjj> leg: new MIME type or new XML schema: more or less the same thing.
[18:07] <lisaDusseault> Thanks Randy :)
[18:08] <hildjj> so, I guess what I'm saying is that text/xml seems like a good format, and then we should argue over what the base DTD/schema should be, and where the extensibility points are.
[18:08] %% lisaDusseault has left.
[18:09] <mrose> let's do something entirely different
[18:12] <hildjj> mrose: different than what?
[18:13] %% lisaDusseault has arrived.
[18:14] <mrose> never mind, it's now obe
[18:15] <akstebbens> what's "obe" -- is this an "oobe"?
[18:15] <hildjj> obe == overcome by events
[18:21] %% hardie has left.
[18:22] <akstebbens> the forward without downloading can be accomplished completely within IMAP without any additional security issues.
[18:23] <akstebbens> a1 APPEND "Outbox" with an external/url part
[18:24] %% hardie has arrived.
[18:24] <akstebbens> either the IMAP server can perform SMTP connections internally, or an external server-based IMAP client can forward messages onto an SMTP server.
[18:27] <leg> obviously it's possible. it's just a question of whether we'd get into the business of having to reimplement all the extensions of SMTP.
[18:31] <akstebbens> runway!!!
[18:34] <hildjj> ok, that makes it make sense for me.
[18:34] <akstebbens> with always on IP networks, IMAP sessions can even do async status, providing a notification status
[18:34] %% leg has left.
[18:34] %% leg has arrived.
[18:43] * mrose has changed the subject to: imap extension issues
[18:45] %% danwing has left.
[18:45] <dcrocker> what was the 'runway' reference?
[18:46] %% leg has left.
[18:46] <hildjj> dcrocker: my comment was after "runway", not in response to it.
[18:46] <hildjj> it was in response to one of pete's statements.
[18:47] <dcrocker> ack. tnx.
[18:47] <randy> But what does "runway" mean in this case?
[18:48] <akstebbens> sorry -- I meant "runaway" ;)
[18:48] <akstebbens> from Monty Python
[18:48] <hardie> clear
[18:48] <hardie> Whoops! Sorry, wrong window....
[18:49] %% rjs3 has left.
[18:50] %% nsb has left.
[18:50] %% leg has arrived.
[18:51] <resnick> So instead of increasing complexity of IMAP composition, we should increase complexity in IMAP's security model?
[18:51] <leg> yes, because we already have universal agreement on IMAP's security model.
[18:54] <randy> In many cases (majority?) the IMAP and submit servers are either the same box or operated by the same organization, so one can trust the other
[18:54] <leg> made by different vendors, might be in different organizational units
[18:55] <randy> Larry, you're suggesting that the servers can't trust each other?
[18:55] <dcrocker> randy, it cannot possible be right to assume a simplistic trust model between independent services.
[18:55] <leg> it's not a slam dunk
[18:56] <randy> But the services often aren't independent. If they are, we have the same problem either direction (IMAP to Submit, or Submit to IMAP)
[18:56] <dcrocker> methinks the resolution between composition-push and submit-pull is going to require two strawman specs to compare.
[18:56] <leg> eh, let's just burn the bandwidth and have the damn devices download and upload. :-)
[18:56] <randy> It's a bit more complex, because there are different proposals for how to do IMAP submission.
[18:57] <randy> I'm saying that if we do IMAP submission, we do it using Submit extensions, because otherwise we fracture the architecture
[18:57] <resnick> [Answer to leg re: "having to reimplement all the extensions of SMTP"] No, we don't. The IMAP uses SMTP and we pass it the SMTP commands we want it to use (perhaps in an annotation as Randy suggested).
[18:57] <dcrocker> randy, imap/submit is a very constrained context, with no surrounding data at risk; by constrast, submit/.mailstore requires much safety to ensure that the submit engine is a) authorized to get what it needs, and b) unable to get anything else.
[18:58] <randy> You still need authorization to submit. Do you want to assume that submission is unauthenticated?
[18:59] %% nsb has arrived.
[19:00] <hildjj> can this just be thought of as proxy auth, like ldap?
[19:00] <dcrocker> imap/submit authorization is a simple, single session authentication. submit/imap requires something like per body-part authentication.
[19:00] %% leg has left.
[19:00] %% hardie has left.
[19:01] <dcrocker> let's do 7:30. it gives me a bit more time to pack, since I have to check out before breakfast.
[19:02] <akstebbens> Dave, did you mistype the wrong window? ;)
[19:02] <dcrocker> sigh. yes.
[19:02] %% wcw has left.
[19:04] %% resnick has left.
[19:04] %% avshalom has left.
[19:04] %% hildjj has left.
[19:05] %% mrose has left.
[19:05] %% eburger has left.
[19:09] %% nsb has left.
[19:11] %% mishizue has left.
[19:13] %% lisaDusseault has left.
[19:18] %% randy has left.
[19:27] %% akstebbens has left.
[19:30] %% dcrocker has left.