[09:42:45] --- Dave Cridland has joined
[09:44:53] --- Dave Cridland has left
[11:40:01] --- Glenn Parsons has joined
[12:48:10] --- Glenn Parsons has left: Disconnected
[15:09:12] --- Glenn Parsons has joined
[15:50:56] --- Glenn Parsons has left: Disconnected
[16:56:20] --- Dave Cridland has joined
[16:58:48] --- GregWhite has joined
[17:07:23] --- cyrus_daboo has joined
[17:07:33] --- NFreed has joined
[17:07:53] --- frodek has joined
[17:08:50] --- kmurchison has joined
[17:10:57] <cyrus_daboo> anyone getting audio?
[17:11:02] <Dave Cridland> Yes.
[17:11:05] <GregWhite> i'm not
[17:11:08] <NFreed> I'm not.
[17:11:27] <NFreed> Just that annoying lumpty-lump background sound.
[17:11:40] <Dave Cridland> Ah. No. I'm intending to get audio.
[17:11:54] <cyrus_daboo> I'm not even getting lumpty-lump!
[17:12:07] <GregWhite> me neither, the connection keeps timing out
[17:12:14] <NFreed> Has there been a room change or something?
[17:12:25] <Dave Cridland> I'm connected fine, I just get a very low rumble.
[17:12:28] <cyrus_daboo> The test stream is playing music, but ietf644.m3u is silent,
[17:12:36] <NFreed> Yeah, that's what I have - a low rumble.
[17:12:45] <cyrus_daboo> Maybe they've not turned the mike back on?
[17:12:56] <Dave Cridland> Anyone in the room itself?
[17:13:08] <Dave Cridland> Ken, you're in Vancouver, right?
[17:13:11] <kmurchison> yes. just people milling around. the mike might be off
[17:13:19] <Dave Cridland> Ah, that's okay, then.
[17:13:38] <NFreed> Isn't the meeting supposed to have started? The times where a bit odd on the schedule...
[17:13:52] <kmurchison> trying to turn th emike on now...
[17:13:55] <kmurchison> mike is on
[17:14:03] <NFreed> And it is working. Thanks.
[17:14:04] <Dave Cridland> Hearing it. A little quiet.
[17:14:43] <GregWhite> i'm still not getting it
[17:14:46] <NFreed> Yes, this isn't as good as dkim. But the audio quality from dkim was GRREEAAATTT.
[17:15:16] <NFreed> Sounds like the usual round of wireless problems.
[17:15:46] --- pguenther has joined
[17:16:01] <kmurchison> yup. intermitent
[17:16:09] <cyrus_daboo> Its certainly not loud. I have my speaker cranked all the way up and I have to have my ear a few inches from it to here Glenn.
[17:16:21] --- tonyhansen has joined
[17:16:35] --- cnewman@jabber.org has joined
[17:16:37] <GregWhite> is http://tinder.uoregon.edu:8000/ietf644.mp3 the correct url?
[17:16:41] --- hardie@jabber.psg.com has joined
[17:16:56] <Dave Cridland> cyrus: Doesn't that kill your eardrums when it clicks and pops?
[17:17:25] <NFreed> Try http://videolab.uoregon.edu/events/ietf/ietf644.m3u
[17:17:26] <cnewman@jabber.org> Having network problems in the meeting room....
[17:17:27] <Dave Cridland> Greg: I followed the link off http://videolab.uoregon.edu/events/ietf/ for the individual room.
[17:17:44] <cyrus_daboo> I've not had anything loud enough to do any damage...yet
[17:17:53] <tonyhansen> I'll tag team
[17:18:47] <tonyhansen> agenda 1: doc status, profile phase 1, reconnect, oma liaison, profile phase 2
[17:19:35] <GregWhite> Dave, I followed the same link, and it tries to connect to the tinder version of the url
[17:19:50] <tonyhansen> brak today after reconnect discussion
[17:20:00] --- Randy has joined
[17:21:35] --- eburger has joined
[17:21:45] <GregWhite> i can't get the audio, the videolab url is getting translated to the tinder url along the way somewhere
[17:22:01] <eburger> Eric is scribing
[17:22:21] <eburger> (but you guys are already there)
[17:23:14] <Dave Cridland> Yes, the m3u playlist file points to http://tinder.uoregon.edu:8000/ietf644.mp3
[17:23:24] <eburger> WGLC slide (slide 11)
[17:24:39] <NFreed> Yes, there appears to be a redirect. When I look in iTunes it shows the URL you mentioned.
[17:24:43] <NFreed> But it is working for me.
[17:24:52] <GregWhite> still not working for me
[17:24:57] <GregWhite> hmmm
[17:25:03] <eburger> Should we continue s2s notifcation requirements?
[17:25:27] <eburger> Current author isn't going to continue work.
[17:25:30] <eburger> Anyone interested?
[17:25:41] <eburger> Corby: Is there any desire to pull the document from the list / charter?
[17:25:51] <eburger> It's been on the list of a year, but no one seems to care.
[17:26:16] <eburger> Could we be superceeding this document with on going work?
[17:26:23] <eburger> Possibly.
[17:26:38] --- Altair71 has joined
[17:26:57] <eburger> Is this work in charter?
[17:27:01] <eburger> Yes: the requirements are.
[17:27:18] --- resnick has joined
[17:27:51] <eburger> Options: ignore, pester existing author, or get new author
[17:28:09] <eburger> Greg: what are nature of changes: ediotrial?
[17:28:20] <eburger> Pete as WG member: vote for dump
[17:28:35] <GregWhite> changes to FUTURERELEASE?
[17:28:35] <eburger> Ted: Tons of editorial comments; document is "less than ideal"
[17:28:40] --- jeaton has joined
[17:28:43] <GregWhite> oh, you mean greg v.
[17:28:51] <eburger> Ted: substantive DISCUSS from Sam H.
[17:29:57] <eburger> Lots and lots of work to do to bring it up to speed
[17:30:02] --- bdesruisseaux has joined
[17:30:44] --- jeaton has left: Disconnected
[17:30:53] <eburger> Ted: still have requirements, whether or not we have a document.
[17:31:04] * resnick wonders why this couldn't have been discussed on the list......
[17:31:07] <eburger> Lisa: if we don't have authors for notification work, then dump everything
[17:31:38] <Dave Cridland> Pete: I'm surprised it wasn't at least raised on the list.
[17:31:50] <Dave Cridland> (Unless it was and I completely missed it)
[17:31:50] <eburger> Any other comments?
[17:31:59] <eburger> New topic: MMS Mapping (Still Slide 11)
[17:32:37] <NFreed> Now things are so faint I can barely make them out.
[17:32:37] --- patrik has joined
[17:32:49] <tonyhansen> <opinion>the s2s stuff was never a good fit for lemonade.</opinion>
[17:33:01] --- patrik has left
[17:33:02] <eburger> All old issues (MMS Mapping) addressed
[17:33:05] <Dave Cridland> Oh, that's a lot clearer. Pete was pretty clear, too.
[17:33:31] <eburger> (Seems like network problems; most people are using mikes)
[17:33:39] --- Glenn Parsons has joined
[17:33:41] <eburger> (I'll try to keep people using the microphones)
[17:34:04] <eburger> MMS Mapping: only issue was a question about 3GPP & 3GPP2 documents, referenced by ENUM
[17:34:09] --- jeaton has joined
[17:34:46] <eburger> Answer: MMS Mapping discusses mapping, not transport
[17:34:51] <eburger> Slide 12: TRIO
[17:35:12] --- cnewman@jabber.org has left: Logged out
[17:35:12] --- jeaton has left: Disconnected
[17:37:03] --- eburger has left: Disconnected
[17:38:11] --- eburger has joined
[17:38:13] <Dave Cridland> I think they have to be, though, since some form of trust relationship is essentially required between the IMAP server and the BURL submit server.
[17:38:39] <Dave Cridland> Unless you use anonymous-accessible URLAUTH URLs, of course.
[17:38:40] <eburger> Discussing URLAUTH
[17:38:53] <eburger> Is it OK to have SUBMIT and IMAP servers only in the same domain
[17:38:58] <eburger> Marc: What is the issue?
[17:39:11] <NFreed> Yes, I'd like to understand the issue as well.
[17:39:14] <Dave Cridland> Damn. Lost audio.
[17:39:23] --- mmealling has joined
[17:39:58] <Dave Cridland> Ned: Basically, if you generate a URLAUTH using submit+ access identifier prefix, then the only way to verify that it's a submission server using it is for the IMAP server to have a trust relationship with the submission server.
[17:40:15] <eburger> [Ted holds Sam's DISCUSS up to Marc and Randy]
[17:40:32] <NFreed> Yes, I agree with that. I'll go read the discuss again.
[17:40:34] <Dave Cridland> Sam's issue is in particular the case where the submission server uses credentials gleaned from PLAIN authentication to it.
[17:40:58] <Dave Cridland> This is not a security consideration.
[17:41:05] <Dave Cridland> This is an operational consideration.
[17:41:28] --- eburger has left: Disconnected
[17:41:38] <Dave Cridland> Well, okay, it's a security consideration in the same way as "We shouldn't be randomly transmitting plaintext credentials between unverified sources"
[17:41:44] --- eburger has joined
[17:42:13] <resnick> Sam Hartman:Discuss [2005-10-26]:I appreciate the excellent work that went into addressing my discuss.I do have one minor point left which I believe still needs to beaddressed. Currently when resolving an imap URL the specificationsays that plain credentials should be passed to the imap server asreceived by the submit server. I agree this configuration should besupported. I agree that this is a reasonable default if the imapserver and submit server are in the same administrative domain. I'mnot convinced it is a reasonable default if the imap server is anarbitrary internet server. I thought I brought this up in thediscussion. I don't see a message where I was convinced that I waswrong nor do I see a response to this specific point.
[17:42:23] <resnick> from: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1751&filename=draft-ietf-lemonade-catenate
[17:42:25] <eburger> Mark: is it only submit+, or all uses of URLAUTH?
[17:42:36] <eburger> Looks like submit+, but we should check with Sam
[17:42:37] <Dave Cridland> But in the larger case, only URLAUTHs which use anonymous access identifiers can be used inter-domain.
[17:42:41] <NFreed> Seems to me that this calls for some text in the security considerations section saying that the usual
[17:43:00] <Dave Cridland> Sam's DISCUSS is *NOT* about submit+
[17:43:00] <NFreed> issues with passwords-in-the-clear apply even though this is server-server not client-server.
[17:43:34] <hardie@jabber.psg.com> Dave: do you want this chanelled to the room? If so, what words?
[17:44:51] <eburger> is it as simple as using SSL or TLS for making the request?
[17:45:08] <eburger> Pete: Why isn't this already addressed in security considerations of IMAP?
[17:45:32] <eburger> This problem isn't specific to BURL / URLAUTH.
[17:45:32] <NFreed> If this is specified elsewhere (and it surely is) perhaps a pointer would sufficie?
[17:45:41] <eburger> Randy: What does "in the clear" mean?
[17:45:42] <resnick> (i.e., it *is* addressed in base IMAP)
[17:45:42] --- tonyhansen has left: Replaced by new connection
[17:45:50] --- tonyhansen has joined
[17:46:17] * resnick is evidently already in a foul mood and it's only Monday
[17:46:45] <eburger> Both servers end up with clear text password, but it is never transmitted in the clear.
[17:47:11] <Dave Cridland> Pete: Cheer up, you haven't tried implementing this stuff yet.
[17:47:18] <eburger> Phil: document doesn't specify how SUBMIT server "logs in"
[17:47:19] <resnick> heh
[17:47:29] <NFreed> Dunno about anyone else, but our customers are pretty tense about passwords-in-the-clear even over their
[17:47:38] <NFreed> internal networks.
[17:48:24] <Dave Cridland> Pete: You can't implement BURL in a client without knowing a priori which server(s) the BURL server means when it advertisies BURL support for "imap".
[17:48:51] <eburger> Chris: Sam asked to have document restate IMAP client requirements in BURL security considerations
[17:49:26] <eburger> Again, so it's handy: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1751&filename=draft-ietf-lemonade-catenate
[17:49:28] <Dave Cridland> How the submit server authenticates to the IMAP server is already covered by RFC3501.
[17:50:26] --- anil srivastava has joined
[17:51:27] <eburger> Chris, Eric, and Glenn will meet with Sam to fully understand his issue.
[17:52:11] <NFreed> Sounds like a good plan. I don't think this is going to be hard to resolve.
[17:52:48] <eburger> SLIDE 13: Future Delivery (Greg V.)
[17:52:58] <eburger> (drum roll as Greg goes to mike)
[17:53:05] <GregWhite> wish i could hear it
[17:53:07] <eburger> Greg W.'s last edit fixed everything
[17:53:15] <eburger> (you've done good :)_
[17:53:24] <GregWhite> thx
[17:53:28] <Dave Cridland> GregWhite: I have an audio connection, and I can *barely* hear it...
[17:53:36] --- cnewman@jabber.org has joined
[17:53:47] <eburger> Some editorial stuff to fix
[17:53:53] <eburger> some i-d nits
[17:53:57] <eburger> one more version of document
[17:54:00] <NFreed> Yeah, the audio seems to get fainter the further we go.
[17:54:08] <eburger> hoping to wait for IESG review
[17:54:14] <eburger> [Greg has a cold :( ]
[17:54:24] <GregWhite> what about the issue Randy brought up on the list today?
[17:54:28] <eburger> Anyone have open issues
[17:54:30] <eburger> which one?
[17:54:42] --- cnewman@jabber.org has left: Disconnected
[17:54:59] <eburger> Randy's point was a syntactic issue. Not substantive. Refers to old version, anyway.
[17:55:05] <anil srivastava> here is randy's comment from e-mail earloer today...
[17:55:07] <anil srivastava> > #2 seems better, because it is more clear on the fact that one can't specify both "holdfor" and > "holduntil" values in the same MAIL FROM command. It's pretty easy to do this in ABNF, isn't it? Perhaps I'm missing something, but off the top of my head: hold = hold-for / hold-until hold-for = "hold-for" delta-time hold-until = "hold-until" RFC3339-date-time Why introduce an extra parameter that serves no purpose ("hold") and needs to be followed by the actual differentiator? So I'd suggest going with #1 ("hold-for" and "hold-until").
[17:55:20] <GregWhite> right, but that came out today
[17:55:35] <anil srivastava> correct..
[17:55:54] <Dave Cridland> Someone did point out an excellent use-case for FUTURERELEASE to me - calendaring programs being able to send reminders for when they may not be running.
[17:55:55] <GregWhite> so, does his comment still apply, that he doesn't agree with my choice?
[17:56:23] <eburger> he's happy
[17:56:33] --- hardie@jabber.psg.com has left: Logged out
[17:56:40] <GregWhite> ok
[17:56:44] <eburger> New version, incorporating nits; after that, we'll send to IESG
[17:56:52] <GregWhite> sounds cool
[17:57:01] <eburger> SLIDE 15: Profile Open Issues
[17:57:08] <cyrus_daboo> Dave: there are some calendar servers that already handle email alerts on behalf of a user when their calendar client is not running.
[17:57:35] <GregWhite> how do they do it?
[17:57:49] <eburger> Consensus on adding BINARY.
[17:57:49] <Dave Cridland> GregWhite: The server's always running.
[17:57:53] <eburger> Anyone don't like it?
[17:58:06] <GregWhite> i see, thanks
[17:58:06] <Dave Cridland> Thanks, Philip.
[17:58:19] <eburger> Phil: if you do BINARY, do you *have* to do content-transfer-encodings?
[17:58:27] <Dave Cridland> No, you don't.
[17:59:03] <Dave Cridland> Cyrus IMAPd, for instance, issues a [UNKNOWN-CTE] response code the moment it sees a literal8.
[17:59:05] <GregWhite> isn't that the whole point of BINARY, so you don't have to do them?
[17:59:17] <eburger> What if someone APPENDS to an S/MIME message?
[17:59:28] <eburger> (from Alexey)
[17:59:42] <eburger> Phil: anyone know when it is OK and not OK to do CTE?
[17:59:49] <Dave Cridland> greg: Yes, you do, because otherwise naïve clients will get binary data, and IMAP doesn't support binary data without using BINARY.
[18:00:27] <Dave Cridland> The specification can be very simple - just do quoted-printable for all text/*, and base64 for everything else.
[18:00:30] <GregWhite> Dave: ok, thanks
[18:00:54] --- hardie@jabber.psg.com has joined
[18:00:57] <Dave Cridland> (If someone wants to nudge Phil and say that.)
[18:01:45] <NFreed> Wonder how DKIM wlll deal with binary MIME?
[18:01:46] <Dave Cridland> I *think* Lyndon was going to do an update to BINARY - I'm guessing he's in Vancouver for this?
[18:01:57] <cyrus_daboo> Actually there are times when a base64 encoding of text (non-ascii) can be more compact that q-p, so in the case of text the server should be able to choose the most compact form itself.
[18:02:37] <NFreed> FWIW, we either do a sample encode of a part of the message or we do a prepass over the message and figure out
[18:02:41] <NFreed> which encoding is best.
[18:02:47] <NFreed> Which one depends on context.
[18:02:48] <cyrus_daboo> Remember you cannot touch any mime multipart security parts - any transform of a signature will break that signature.
[18:02:49] <Dave Cridland> Ned: I wouldn't expect to see DKIM ever have to deal with Binary MIME messages, actually - I see them as client-server and server-client, not server-server.
[18:03:22] <NFreed> Interesting you would say that. That's more or less how we're planning to implement it. I don't feel good
[18:03:40] <NFreed> about the effects of firewalls on binary SMTP on the open Internet.
[18:04:13] <NFreed> Perhaps binary would get better traction as a submit extension and not an SMTP extension?
[18:04:14] <Dave Cridland> Cyrus: Agreed, but you can make a strong specification by saying "use QP for text, base64 for everything else". And perhaps more to the point, it's pretty rare to see Binary be used for text. Someone's got to be sending pretty long lines without using format-flowed.
[18:04:15] <eburger> Mark: difference between BINARY and 8BIT is that BINARY allows NUL
[18:04:38] <Dave Cridland> Ned: I thought it was, in the newer RFC.
[18:04:45] <tonyhansen> and lines are limited to <998 bytes
[18:04:50] <eburger> Stephane: Any reason to have BINARY>
[18:04:54] <NFreed> Could be. I haven't read it in a while.
[18:04:57] <eburger> Answer: wireless efficiency
[18:05:14] <Dave Cridland> I posted some comparisons between JPEG+base64+gzip and JPEG to the list.
[18:05:32] <Dave Cridland> gzip doesn't recover the loss from base64, in short.
[18:05:54] <Dave Cridland> Plus doing it that way involves two encoding functions.
[18:06:17] <eburger> Greg V: need BINARY for sending, e.g., a picture, directly (over SUBMIT), without building a template first.
[18:07:29] <eburger> Glenn: is there a problem with S/MIME when CTE's occur?
[18:07:51] <eburger> Alexey: we can (1) add text to explain how to avoid problems or (2) punt
[18:08:00] <NFreed> The problem with both S/MIME and PGP can be solved by defining a new hashing methodology.
[18:08:08] <Dave Cridland> The problem with adding BINARY to the profile is that clients will attempt to use it - and then that can cause an additional round-trip *and* wasted transmission.
[18:08:22] <eburger> Greg V: what about just simple BINARY download and SUBMIT, but keep BINARY APPEND for phase 2
[18:08:24] <NFreed> This has been on my to-do list for years but there has never been enough interest to drive me to complete it.
[18:08:51] <Dave Cridland> (I mean, in the case where BINARY is used in an APPEND, but the IMAP server responds with UNKNOWN-CTE)
[18:08:57] <Dave Cridland> I do object.
[18:09:12] <Dave Cridland> To allowing IMAP BINARY without supporting APPEND.
[18:09:17] <cyrus_daboo> Ned, do you mean doing the hash BEFORE doing the CTE etc?
[18:09:55] <NFreed> Yes, that's part of it. You have to hash each part content separately, then compute a hash over all the hashes and headers
[18:10:01] <NFreed> excluding CTE fields.
[18:10:02] <Dave Cridland> It'd be okay if there were a per-mailbox signalling mechanism.
[18:10:02] <pguenther> I'll track down the S/MIME issue; I'll be seeing Blake later
[18:10:21] <eburger> Greg V: BINARY document is the problem, not the Profile
[18:10:34] <eburger> (BINARY draft, not the object...)
[18:10:37] <Dave Cridland> Yes. BINARY doc needs a revision.
[18:10:38] <NFreed> This has a number of advantages. One is that you can precompute the hash on body parts, making the computation
[18:10:45] <Randy> Interesting suggestion, Ned: that binary is more useful as client-server optimization and not server-server, and hence makes more sense as submit extension.
[18:10:45] <Randy> Sounds reasonable.
[18:10:59] <Dave Cridland> Can someone track down Lyndon and ask him if he's doing a revision?
[18:11:07] <NFreed> of the signature when you send the message much simpler. (You probably want to use ECC as well, for obvious reasons.)
[18:11:13] <eburger> WE can do that
[18:11:44] <NFreed> Randy: Yes, I'm pretty worried about attempting to use binary on the open Internet. There are just too many
[18:11:47] <Dave Cridland> I know he had one planned, since there's issues with LITERAL+ interaction too.
[18:11:56] <NFreed> busted "stateful inspection" widgets out there.
[18:12:15] <cyrus_daboo> Yes that makes sense. It should also allow forwarding parts of a signed message whilst still maintaining the original signature on each part, right?
[18:13:13] <Randy> Greg White: I still don't like the ABNF, and have a suggestion I'm trying to send to the list, but have been thwarted by the lousy connectivity here. (I also am not happy with the syntactic choice, as it seems pointlessly ugly to me, but I won't object on that ground alone. I'm not sure why it seemed better, but in the end it's just extra syntactic noise.) I think the ABNF can be improved, making the document more readable.
[18:13:22] <NFreed> Cyrus: You'd have to embed signature data in addition to hash data for that.
[18:14:14] <Dave Cridland> We *could* do a mini draft that was a cut-down BINARY for downloading only, and did not advertise "BINARY" as such.
[18:14:17] <eburger> Proposal to not put BINARY in Profile Phase 1
[18:14:39] <eburger> 2x 1/2 drop, 1 wants to keep; 25 don't care
[18:14:39] <Dave Cridland> That would solve the APPEND problem, or at least postpone it.
[18:15:13] <Dave Cridland> The FETCH side of BINARY is very valuable.
[18:15:44] --- mmealling has left
[18:15:47] <Dave Cridland> (If someone would like to act as my voice for the past three sentences, unless that's been raised?)
[18:15:52] <eburger> Greg V: Profile 1 is pretty useless without BINARY
[18:15:59] <eburger> Will take to list
[18:16:00] <pguenther> Greg spoke on that
[18:16:04] <Dave Cridland> Ah, good.
[18:16:37] <GregWhite> Randy: i'll look for your comment on the list, thank you
[18:17:02] <Randy> Dave, wouldn't the client check to see if BINARY is advertised before trying to use it?
[18:17:22] <Dave Cridland> Yeah. And it still can be, without allowing literal8 support in APPEND.
[18:17:45] <Dave Cridland> What's the issue Alexey's calling on? I missed the audio.
[18:17:56] <Randy> Dave, never mind, you explained what you meant later. Sorry.
[18:18:04] <eburger> $Forwarded
[18:18:14] <Dave Cridland> Oh, right.
[18:18:46] <eburger> Now talking about FCC
[18:18:50] <Dave Cridland> Randy: Want to suggest that LEMONADE client all implement the personality ACAP dataset class?
[18:19:00] <cyrus_daboo> The problem with sent-mail mailbox descovery is that you probably want to go further and find Trash, Drafts etc as well.
[18:19:04] <eburger> Greg V. noticed lots of text about FCC, but with no solution.
[18:19:16] <eburger> Felt that was odd.
[18:19:42] <eburger> Alexey: problem is potential for clients doing different stuff
[18:20:21] <eburger> Profile is "no worse" than current situation. Since most people use 1 client, not really an issue.
[18:20:45] <eburger> Alexey: OK to defer how to discover SENT MAIL folder to Profile 2?
[18:20:51] <eburger> (no objections here)
[18:21:18] <anil srivastava> i am ok with that as long as we address the concerns Cyrus raised earlier... i.e trash, draft and sent mail should have a similar resolution.
[18:21:36] <eburger> Bullet 5: Greg V: 2 ways to submit a message. CATENATE into draft and forward with BURL; or send sequence of BDAT and BURL
[18:21:45] <Dave Cridland> Anil: Get Randy to rev the personality dataset class, then. It works fine. :-)
[18:21:47] <eburger> Never enumerate them in the document
[18:22:15] <eburger> Stephane: OK to take out mention of different methods?
[18:22:46] <eburger> Leaning towards CATENATE only.
[18:22:46] <Dave Cridland> Both are supported, in terms of the extensions.
[18:22:59] <Randy> Dave: tempting, but I doubt we can require ACAP.
[18:23:01] <eburger> Alexey just said what Dave said.
[18:23:24] <Dave Cridland> So both should be described. WHich gets used depends on whether you also need FCC, and whether you have a client that additionally understands POSTADDRESS or not.
[18:23:31] <eburger> Alexey: should we have one example (CATENATE only) or two (with BURL/BDAT)?
[18:23:53] <Dave Cridland> Randy: It's the standards track solution for this problem, after all.
[18:24:29] <Dave Cridland> Tell Alexey I can do him a few examples.
[18:24:47] <cyrus_daboo> ANNOTATEMORE or NAMESPACE have also been discussed as a solution to trash, drafts, sent etc. Neither requires a separate protocol.
[18:25:23] <Dave Cridland> Does he want the same example as the CATENATE example, just performed using BURL/BDAT?
[18:25:45] <Randy> I'm happy to rev personalities if anyone wants it
[18:25:52] <anil srivastava> requiring ACAP would be a non-starter. Cyrus has the right idea.. personally I lean towards ANNOTATEMORE
[18:26:31] <Dave Cridland> Anil: Yes, you could use a server-wide annotation.
[18:26:38] <kmurchison> Dave: using the same example makes sense to me
[18:26:40] <eburger> Summary: issues 1 & 3 are in. 2 is fixed in 2 weeks. 4 is out (clearer text). 5 need examples.
[18:26:49] <eburger> Dave can you get examples in 2 weeks or less?
[18:27:04] <Dave Cridland> Anil: I wish you luck in defining exactly what a sent mail mailbox is, though. And how to get the semantics you want.
[18:27:10] <Dave Cridland> Yes, no problem.
[18:27:21] <Dave Cridland> Probably by Wednesday.
[18:27:22] <eburger> thanks
[18:27:38] <eburger> New draft by 11/28.
[18:28:26] <eburger> SLIDE 17: Reconnect
[18:28:29] <anil srivastava> as Alexey said earlier - not getting an agreement (which I am hopeful for) is no worse than the current state :-)
[18:28:52] <eburger> Slides are on Supplemental site: http://flyingfox.snowshore.com/i-d/lemonade/slides64/Quick%20Reconnect.ppt
[18:29:02] <eburger> SORRY: PPT only. Will get PDFs later
[18:29:29] <eburger> Corby
[18:29:47] <eburger> A bunch of changes came in before draft deadline, so missed submitting -05
[18:29:55] <Dave Cridland> Anil: As Mark said, no, it's not, because you run the risk of alientating clients from being conformant after the fact.
[18:29:58] <eburger> break out session-id command.
[18:30:39] <eburger> Made major changes to command structure
[18:30:50] <eburger> What took so long was examining and working through edge cases
[18:30:53] <Dave Cridland> I can barely make out anything being said, sorry.
[18:31:01] <eburger> New command: SID (you can call it QR)
[18:31:05] <eburger> better?
[18:31:16] <eburger> SID can be issued any time during session.
[18:31:26] <eburger> Problem is for client cache management
[18:31:36] <eburger> client can get unsolicited new SID
[18:31:51] <eburger> e.g., server figures out client is better off getting refresh
[18:32:10] <anil srivastava> dave: that would be when this is mandated. Conformant clients can get consistent behaviour
[18:32:37] <Dave Cridland> Audio's a little better, yeah.
[18:32:42] <eburger> ADVANCED USE CASES
[18:32:59] <eburger> Mobile client that gets docked.
[18:33:14] <eburger> Don't need quick reconnect, so can tell server to release server resources.
[18:33:30] <eburger> When you go mobile, client can restart SID processing on server
[18:34:17] <eburger> Summary: Might have draft in time for Interim, if we have one (January?)
[18:34:40] <eburger> SLIDE 18: 2192bis
[18:34:42] <Dave Cridland> This is trying to do mobility in the application layer, isn't it? And surely if SID is a round-trip, then you're adding one round-trip (SID) to save another (FETCH), the latter being pipelinable anyway with the SELECT.
[18:35:40] <eburger> Pete: Use of the Trio would be much enhanced if we wait for 2192bis
[18:36:06] <eburger> Mark: Trio substantially modifies 2192; 2192bis fixes this.
[18:36:18] --- Randy has left: Disconnected
[18:36:34] <eburger> Better to refer to 2192bis
[18:37:27] <eburger> Alexey: Changes: - new URI's, which get us IPv6, etc. - mailbox naming scope - partial fetch modifier
[18:38:08] <eburger> Phil: with 2192bis, something that supports 2192 would not support bis (partial fetch)
[18:38:34] <eburger> Pete: URLAUTH would benefit from this; CATENATE would benefit from partial fetch
[18:38:53] <eburger> Stephane: partial fetch needed for partial composition of document (required for OMA)
[18:39:03] <eburger> Stephane: but can wait for phase 2
[18:39:04] --- bdesruisseaux has left: Disconnected
[18:40:03] <eburger> SLIDE 19: CONVERT
[18:40:29] <eburger> Glenn: are there any open issues needed to be discussed?
[18:42:10] --- Randy has joined
[18:43:05] <eburger> SLIDE 20: OMA Liaison
[18:46:55] <eburger> Discussion: In London, we said we would look at a potential IETF realization of the OMA Architecture Document. Give a response to each requirement in the Requirement Document. Similar to what we did before. Of the requirements, we say which we address, as well as what we don't (e.g., charging, lobotomize-self, etc.).
[18:47:20] <eburger> Need to put together a proposal that is the set of repsonses to the requirements, as well as fill in detail on Architecture Document.
[18:47:35] <eburger> Vehicle will be an Internet Draft.
[18:47:45] <eburger> We then send Liaison to OMA, referencing Draft.
[18:48:25] --- cnewman@jabber.org has joined
[18:48:26] <eburger> Greg V: We created a response to preliminary requirements. Greg noticed that most requirements changed; about 20 new requirements.
[18:48:40] <eburger> Possibly merge in Stephane's OMA document
[18:48:49] <eburger> More discussion on Wedesday
[18:49:20] <eburger> Stephane: Go through *each* requirement, or go through our architecture and then just have a table of "we do x, y, z".
[18:49:26] <eburger> Greg V: do both
[18:50:53] --- eburger has left
[18:52:13] --- eburger has joined
[18:53:16] <eburger> Glenn: Only issue we may see is that the OMA Architecture (Section 5) has a single, monolithic E-Mail server. IETF model has two functions, Access and Submission
[18:53:46] <eburger> We need to make sure we properly convey the architecture
[18:54:04] <eburger> Goal: prepare a document in time for OMA's next meeting.
[18:54:30] <eburger> (next meeting is December 11-17 in Athens, Greece)
[18:56:39] <anil srivastava> which picture is being referenced in the conversation in the room? Is it from the OMA RD?
[18:56:57] <eburger> Goal is to get agreement in principal by Wednesday, to discuss at IETF, to get documents reviewed, in time for Greece
[18:57:02] <eburger> Anil: yes, from the OMA RD
[18:57:06] <anil srivastava> thx.
[19:00:02] --- Altair71 has left
[19:00:44] <eburger> Also (Anil, and others), take a look at the 63.5 slides on the Supplemental Web Site.
[19:01:38] <eburger> Anything from the Radio audience?
[19:02:26] --- resnick has left
[19:02:40] --- hardie@jabber.psg.com has left: Logged out
[19:02:47] --- cyrus_daboo has left
[19:02:50] <Dave Cridland> Not from me. See you Wednesday (at a more civilised time)
[19:02:52] --- kmurchison has left
[19:03:16] <Glenn Parsons> Thanks for staying up Dave.
[19:03:39] <Dave Cridland> A pleasure.
[19:04:37] --- anil srivastava has left
[19:05:05] --- cnewman@jabber.org has left: Disconnected
[19:05:22] --- Anil Srivastava has joined
[19:05:31] <eburger> bye guys!
[19:05:34] --- eburger has left
[19:05:36] <Anil Srivastava> bye
[19:05:38] <Dave Cridland> Night, night, all.
[19:05:42] --- Anil Srivastava has left
[19:05:46] --- Dave Cridland has left
[19:06:45] --- frodek has left
[19:07:39] --- GregWhite has left
[19:08:23] --- Randy has left
[19:20:05] --- Glenn Parsons has left: Disconnected
[19:21:12] --- NFreed has left
[19:24:12] --- tonyhansen has left: Replaced by new connection
[19:49:53] --- pguenther has left
[19:54:40] --- corby has joined
[19:54:45] --- corby has left