[09:12:38] --- pguenther has joined
[11:43:28] --- pguenther has left
[12:02:03] --- LOGGING STARTED
[12:57:50] --- NFreed@jabber.org has joined
[13:00:05] --- pguenther has joined
[14:10:21] <NFreed@jabber.org> Philip: I just reviewed your message regarding non-UTF-8 in strings. It looks like the right change to me.
[14:10:50] <NFreed@jabber.org> All things being equal, I would have preferred for there to be a quoting mechanism for octets and require legal
[14:11:10] <NFreed@jabber.org> UTF-8 everywhere, but it would have to be in the base and as you well know it is too late to add it.
[14:16:54] <pguenther> just saying "if you want to put iso-8859-1 in a vacation :mime then quoted-printable it" won't fly?
[14:22:04] <NFreed@jabber.org> I'm more concerned with wanting to be able to i;octet match random 8bit crap in headers.
[14:22:54] <NFreed@jabber.org> But there may well be cases where someone doesn't want quoted-printable used too.
[14:23:07] <NFreed@jabber.org> Lotta broken out there...
[15:02:29] --- kjetilho has joined
[15:11:59] --- Randall Gellens has joined
[15:17:15] <kjetilho> action on the audio feed :)
[15:19:46] --- Barry Leiba has joined
[15:20:15] * Barry Leiba has changed the subject to: Sieve session at IETF 66, start time approaches rapidly...
[15:21:08] --- cyrus_daboo has joined
[15:21:11] <kjetilho> everyone here except me are physically present?
[15:22:09] <Barry Leiba> Ned is not.
[15:22:23] <Barry Leiba> More's the pity.
[15:22:27] <Barry Leiba> We miss you, Ned.
[15:22:55] <kjetilho> very faint audio
[15:23:04] <kjetilho> (but it may be just chatter :)
[15:23:15] --- kdz has joined
[15:23:17] <cyrus_daboo> Barry is acting as channel in the room for jabber posts
[15:24:23] <Barry Leiba> Kjetil: Can you hear my microphone OK?
[15:24:30] <kjetilho> the audio is still quite low
[15:24:41] <kjetilho> but I can turn the volume up to 11
[15:24:51] <Barry Leiba> How about Phillip's mike?
[15:25:03] --- tonyhansen has joined
[15:25:10] <kjetilho> inaudible now
[15:25:16] <tonyhansen> definitely need the 11 value
[15:25:32] --- alexeymelnikov has joined
[15:26:11] * Barry Leiba has changed the subject to: Sieve session at IETF 66, start time approaches rapidly...3 minutes...
[15:26:30] --- stpeter has joined
[15:26:42] --- hardie@jabber.psg.com has joined
[15:27:03] --- eburger has joined
[15:27:09] * Barry Leiba has changed the subject to: Sieve session at IETF 66, start time approaches rapidly...2 minutes...
[15:27:55] <stpeter> alexeymelnikov: I'm in the SIMPLE meeting, if you want or need me to jump in the Sieve room for xmpp-notify discussions, let me know
[15:28:07] * Barry Leiba has changed the subject to: Sieve session at IETF 66, start time approaches rapidly...1 minute...
[15:28:08] --- tonyhansen has left: Replaced by new connection
[15:28:30] --- kmurchison has joined
[15:30:04] * Barry Leiba has changed the subject to: Sieve session at IETF 66, called to order
[15:30:40] <alexeymelnikov> Peter: we just need to talk for 2 minutes about XMPP notification. After this meeting?
[15:30:49] <stpeter> sure, sounds good
[15:30:58] <kdz> Cyrus calls session to order, notes well
[15:31:01] <kdz> bashing agenda
[15:31:27] <kdz> jumping in
[15:31:36] --- jhutz has joined
[15:32:02] <kdz> Cyrus presents WG status
[15:32:46] <kdz> http://www3.ietf.org/proceedings/06jul/agenda/sieve.txt
[15:33:10] <jhutz> Hm. Isn't "approved - announcement to be sent" one of those states that has substates recorded only in Amy's head?
[15:33:59] <hardie@jabber.psg.com> what's the draft string?
[15:34:21] <jhutz> draft-ietf-sieve-editheader-04.txt
[15:34:26] <kdz> one change for header
[15:34:29] <kdz> minor issues with body
[15:34:47] <Barry Leiba> Ted: you mean for imapflags?
[15:35:14] <Barry Leiba> draft-ietf-sieve-imapflags-05
[15:35:20] <kdz> s/header/editheader/
[15:35:35] <kdz> base-spec:
[15:35:37] <hardie@jabber.psg.com> I found it. That is a bit odd. I don't see any reason it should not have been announced.
[15:36:09] <kdz> phil: sent note to list detailing issues, on screen as well
[15:36:30] --- Chris Newman has joined
[15:38:29] <kdz> phil: discussing "do we want to permit arbitrary octets in strings? phil discussing "permit arbitrary octets in strings" questions
[15:38:58] --- 莉沙 has joined
[15:39:39] <kdz> - ignore the problem - not an issue in practice (revert to 3028 ABNF -- not UTF-8)
[15:39:55] <kdz> - create new syntax element
[15:40:42] <kjetilho> I think it is a big problem that we can't trust Sieve scripts to be pure UTF-8. it complicates everything.
[15:40:48] <kdz> Phil: As 3028 allowed arbitrary octets, suggests revert.
[15:41:19] <kdz> alexey: it's way too late now
[15:41:34] --- tonyhansen has joined
[15:41:35] <kjetilho> the intent of the language is quite clear, everything is Unicode
[15:41:37] <alexeymelnikov> ... to fix this
[15:41:48] <kdz> phil to back fill poetry into jabber log
[15:41:49] <kjetilho> I never realised anyone interpreted it otherwise
[15:42:43] <kdz> phil: bad for GUIs trying to display this
[15:42:55] <kdz> ... parsing problematic
[15:42:57] <kjetilho> can the script writer know how the string in his script is represented for an i;octet-test?
[15:42:59] <Barry Leiba> Ned, want to weigh in?...
[15:43:12] <alexeymelnikov> GUI for vacation needs to parse MIME in order to be able to display message correctly.
[15:43:32] <NFreed@jabber.org> I don't like any of the options here, but the one I dislike least is to allow non-UTF8 in quoted strings.
[15:43:44] <NFreed@jabber.org> I wish we had put an escape mechanism in the base.
[15:43:56] <kjetilho> I want an escape mechanism, too
[15:44:25] <kjetilho> correct, that's my question
[15:44:52] <NFreed@jabber.org> Which solves the "what charset am I using issue
[15:46:12] <kdz> jhutz: problem is user type characters, not octets, makes it difficult to produce proper octets
[15:46:54] <alexeymelnikov> Jeff: how does the user know which octets to type in in order to produce a script testing for specific octets. User needs to know what mappings are to be performed by Sieve.
[15:47:58] <kdz> barry: need to separate out GUI issues from protocol issues
[15:49:06] <kdz> jh: w/ i;octet-test, user cannot generate arbitrary octets if restricted to UTF-8
[15:49:14] <kdz> Barry: that's a UI issue.
[15:49:44] <kjetilho> i;octet wasn't important for me. I just want an invariant for strings in scripts to reduce confusion. consider an editor where you add a :mime with Latin1, but the editor was in Unicode. this means it will be wrongly tagged.
[15:50:17] <kdz> phil: to put text in to revert
[15:50:34] <kjetilho> since the editor will not transcode it for you
[15:50:49] <NFreed@jabber.org> Well, if just-send-non-UTF-8 isn't going to play, how about the string-escape extension idea?
[15:51:06] <NFreed@jabber.org> I could live with that, but we need the extension sooner rather than later.
[15:51:26] <NFreed@jabber.org> This was Philip's idea first, BTW.
[15:51:32] <NFreed@jabber.org> OK, you want me to write it?
[15:51:34] <jhutz> A string-escape extensions sounds like a great idea!
[15:51:35] <jhutz> Yes!
[15:51:37] <kdz> Ned to volunteer to write it
[15:51:41] <NFreed@jabber.org> Suggestions as to syntax?
[15:51:58] <jhutz> Uh, the typical \-escapes?
[15:52:04] <jhutz> \nnn or \xXX
[15:52:13] <jhutz> Either that, or HTTP-stype %xx
[15:52:19] <jhutz> s/stype/style/
[15:52:49] <alexeymelnikov> Ned+Philip will write an ID on escaping mechanism
[15:53:17] <kdz> phil: to put in text elaborating on the problem
[15:54:02] --- 莉沙 has left: Logged out
[15:54:16] <stpeter> k
[15:54:24] <stpeter> oops, wrong window :-)
[15:54:32] <kdz> q to lisa regarding AUTH48 change in IANA templates
[15:54:48] <tonyhansen> (we have a "k", anyone for an "l"?)
[15:55:59] <kdz> authors and editors to address IANA issue when core reaches AUTH48
[15:56:08] <jhutz> Ew. The Description fields for the extensions registered in 3028bis suck.
[15:56:20] <kdz> now on to comparators
[15:56:38] <jhutz> Capability name: fileinto Description: Adds the 'fileinfo' action
[15:56:46] <kdz> alexey asks for others to review base spec use of comparators
[15:57:20] <Barry Leiba> Jeff, you don't like the stating of the bleeding obvious?
[15:57:24] <kdz> on to MIME loops
[15:58:21] <pguenther> hmm, need to change 'indication' to 'indicated' in the comparator-* description
[15:58:41] <kdz> Cyrus: WG consensus appears to allowing nestings but have a implementation defined depth
[16:01:45] <jhutz> I'd rather it said the non-obvious, like "adds an action to do XYZ"
[16:04:28] <pguenther> ah, to state the use of the added action
[16:06:54] <kjetilho> consider the RFC822 attachment to be an extra child in the tree, so it iterates into it?
[16:07:02] <kdz> cyrus: test the nearest set of rfc822 headers?
[16:07:22] <kdz> lisa: wouldn't there be de-encaps?
[16:07:38] <Barry Leiba> Kjetil: it is, and it does, I think.
[16:08:28] <kdz> Cyrus: use is not limited to EAI
[16:08:32] <kjetilho> barry: ok, I thought only MIME headers was checked, so the attachment was body
[16:08:45] <kjetilho> (including the RFC822 headers)
[16:09:19] --- eburger has left: Replaced by new connection
[16:09:25] <kdz> barry: thinks header: refer to (nearest) outside headers
[16:09:34] <Chris Newman> The EAI group does not have rough consensus that the encapsulation approach is a good one. So the EAI parts of this discussion are useful only as feedback to EAI about problems the encapsulation approach will case.
[16:10:08] <jhutz> The present issue isn't really unique to EAI; that was just an example.
[16:10:48] <kdz> alexey: who wants to add next text for the encap parts?
[16:11:10] <kdz> more yes, few (or zero) no
[16:11:43] <alexeymelnikov> Ted: you don't want to allow message/*, there are some weird things registered.
[16:12:30] <hardie@jabber.psg.com> Not weird, just not necessarily easy to handle here, and adding parsing logic for them when they won't really be used is not needed
[16:13:06] <kdz> phil: not just closest enclosing, but closest enclosing plus me
[16:13:17] <hardie@jabber.psg.com> You won't see message/sipfrag enclosing a message/cpim, with message/rfc822 in the middle very often.
[16:13:22] <Chris Newman> The ability to test the headers in text/rfc822-header part of a DSN with header-only return would be interesting.
[16:13:58] --- stpeter has left: Replaced by new connection
[16:15:19] <kdz> cyrus: this is a body test
[16:15:35] <kdz> phile: it would be nice to do a header test on the body
[16:15:55] <kdz> phil: back to list?
[16:15:57] <kjetilho> was this ever on the list?
[16:16:05] <pguenther> nice call, chris
[16:16:06] <Barry Leiba> Not sure
[16:16:11] <kdz> cyrus: design team.
[16:16:44] <kdz> on to Regex
[16:17:13] <Barry Leiba> Ned: comments on regex?
[16:17:16] <kdz> Alexey: dragging on.. should we drop this?
[16:17:44] <kjetilho> I think regex is an essential feature
[16:17:50] <kdz> cyrus: should this remain WG charter work
[16:17:59] <NFreed@jabber.org> I haven't had time to work on it, sorry. Hopefully very soon.
[16:18:26] <kdz> Alexey: which implementations support regex?
[16:18:40] <alexeymelnikov> Cyrus & Isode (derived from Cyrus) do
[16:18:59] <kdz> anyone else?
[16:19:09] <kjetilho> I'm using Cyrus, yeah
[16:19:28] <kdz> okay, so just cyrus (and derivatives)
[16:19:43] <NFreed@jabber.org> I have a partial regex implementation. My comparator support is weak.
[16:19:56] <Barry Leiba> Ned: would you rather continue, or drop it?
[16:20:15] <kdz> Ned: or push it to individual?
[16:20:58] <kjetilho> I don't have deep enough understanding of comparators yet, but ...
[16:21:55] <NFreed@jabber.org> Let me see if can get it done this week. If not I'll hand it off to someone else.
[16:22:04] <NFreed@jabber.org> Lotta work to do...
[16:22:19] <alexeymelnikov> Ned: did I make you feel guilty :-)?
[16:23:05] <NFreed@jabber.org> I always feel guilty because I'm always behind ;-)
[16:23:27] <kdz> alexey notes a remaining issue of which regex to use
[16:24:06] <alexeymelnikov> we need to pick which regex standard to use
[16:24:30] <kdz> posix? unicode?
[16:24:50] <NFreed@jabber.org> Feel free to email me regarding regex choices...
[16:24:53] <kdz> jh + chairs: defer
[16:25:39] <kdz> next topic: reject/refuse
[16:25:44] <jhutz> of course, the set I would argue for is perl-compatible
[16:25:51] <kdz> alexey: three remaining issues
[16:26:25] <jhutz> which is basically the only truly logical RE syntax I've seen. Of course, I don't suggest the full perl RE syntax, including things like embedded code.
[16:27:27] <jhutz> Why should two actions ever be artifically declared incompatible?
[16:27:51] <jhutz> Sure, reject/refuse should suppress the default keep. It shouldn't be incompatible with fileinto, and it shouldn't be incompatible with keep.
[16:28:11] <NFreed@jabber.org> Make the regex flavor a parameter? Yeech.
[16:28:13] <kjetilho> jhutz: it's a MUST from RFC 2821, so it has to be incompatible
[16:29:10] <jhutz> Ned, I agree. Pick one and be done with it. The only thing worse than bad RE syntax is multiple RE syntaxes
[16:29:35] <kmurchison> ned, jeff: POSIX EREs which the I-D is based on are a subset of Perl REs
[16:30:09] <kdz> phil: prior specs say don't continue processing messages you reject
[16:30:28] <jhutz> kjetilho, can you give a specific reference?
[16:30:34] <jhutz> (within 2821)
[16:30:44] <jhutz> ken, why aren't you here?
[16:31:17] <kdz> william leibzon speaking
[16:31:18] <kjetilho> Jeff: 4.2.5
[16:31:26] <kmurchison> jeff: too much family stuff
[16:31:53] <NFreed@jabber.org> Have to bail, sorry. Talk to y'all later.
[16:31:56] --- NFreed@jabber.org has left: Logged out
[16:32:43] <kdz> speaker: the 521 reference is to avoid loops
[16:33:34] <kdz> last speaker was randall
[16:34:37] <Randall Gellens> I meant not just "loops" but related problems -- if the user gets a bounce and resubmits the message but the server delivered the first one, that's a problem
[16:34:52] <kdz> jh: don't leave this behavior to implementations
[16:35:42] <kdz> barry: generally doesn't like SHOULD
[16:36:53] <jhutz> If they get a bounce and resubmit, that's a new message?
[16:37:39] <kdz> lisa suggested "reject-more" as name, kurt suggested "punt"
[16:37:49] <kjetilho> jhutz: well, that depends, the client might reuse the Message-ID ...
[16:38:12] <kjetilho> (not 100% sure it's allowed, but I think so.)
[16:38:57] <jhutz> Then that client is broken. If the user sends a new message, it's a new message, and should have a new message ID. IMHO.
[16:39:06] <alexeymelnikov> Do we need a new action that is compatible with fileinto/redirect?
[16:39:19] <kdz> bh: we went from MUST to SHOULD, seems some want to go the other way
[16:39:29] <alexeymelnikov> We need to poll implementors
[16:39:35] <kdz> s/bh/bl/
[16:40:30] <kdz> -- non-assci text in reject string?
[16:41:40] --- kmurchison has left
[16:41:54] <kjetilho> with variables, the reason string can be constructed during run-time
[16:42:10] <kdz> William: 5th choice: alternative string
[16:42:25] <Chris Newman> Encode the UTF-8 string in a data: URL? :-)
[16:43:32] <kjetilho> I don't think it's bizarre to offer to enter two strings, one in local language and one in English
[16:45:27] <kdz> barry: pref #3 (dont' send custom string), maybe #1 (strip UTF-8)
[16:46:18] <kdz> kurt: stripping is evil (use of a replacement character would be slightly better).
[16:47:05] <kjetilho> I would like reuse of RFC 2047 encoded-words, but that's an SMTP extension, and unfortunately off-topic
[16:47:11] <kdz> barry: nobody likes DSN
[16:47:32] <jhutz> This room could benefit from extra mics like we had in krb-wg yesterday
[16:47:58] <kdz> phil: yes (nobody likes DSN) . notes purpose of this is to avoid DSN generation
[16:48:56] <Chris Newman> A clever implementation could stuff the reject text into a public http URL and include generic error with the http URL for details. I wouldn't want to forbid such an implementation, but neither is it reasonable to require that.
[16:49:54] --- stpeter has joined
[16:51:54] <kdz> discussion seems to go back to option #3
[16:52:05] <jhutz> That is clever. I think there is increasing consensus for using an implementations-defined string in cases where the user-provided string is UTF-8 and we can't do UTF-8
[16:52:44] <jhutz> are we still on time?
[16:52:52] <kdz> on to notification
[16:53:09] <Barry Leiba> I think we're 15 minutes behind.....
[16:53:12] * stpeter cheers for notification
[16:55:01] <jhutz> I really don't remember the decision last time. I remember arguments for parallelling XMPP, and arguments that notify is not xmpp-specific
[16:56:26] <kjetilho> where's importance defined in XMPP?
[16:56:50] <kdz> alexey: establish IANA registry now or later?
[16:57:03] <Chris Newman> :option "alarm" "audio"
[16:57:07] <kdz> kurt: practice is to establish registry when one defines the extensible parameter
[16:57:14] --- stpeter has left: Replaced by new connection
[16:58:54] <pguenther> :option "editor" 6
[16:59:40] <kjetilho> generic options valid for all methods should be explicit :keywords
[16:59:42] --- stpeter has joined
[17:00:24] <kdz> seems folks concur that separate options and method registries are needed (at time these extensible parameter are defined)
[17:07:03] <kdz> discussion of normative ref to JEP....
[17:07:55] <jhutz> I think this is a non-issue at this point.
[17:10:00] <kdz> cookies in ten
[17:10:47] <alexeymelnikov> Ned: please LC the date extension
[17:10:49] --- stpeter has left: Replaced by new connection
[17:11:01] <kdz> re: jep norm ref: Ted suggests the WG move forward regardless of concerns, issues are resolvable
[17:11:23] <kdz> on to manageSieve
[17:11:25] <kjetilho> (I think it's weird to mix index and date in same document, especially since there can never be more than one Date header)
[17:11:42] <kjetilho> oh, never mind. it's due to Received, of course.
[17:12:03] <kdz> on to include
[17:12:37] --- stpeter has joined
[17:13:03] <kjetilho> *hand*
[17:13:38] <kdz> a few hands raised to alexey's question re who has read sieve-include
[17:14:07] <kdz> alexey: back to list
[17:14:21] <kdz> cyrus: if anyone has an alternative, please post specifics
[17:14:23] <kjetilho> the base spec might define a "header" section which can only contain require.
[17:14:45] <kjetilho> then include can specify that import/export only goes in that header.
[17:15:05] <kjetilho> or preamble, rather than header
[17:15:08] <kdz> cookies in five
[17:15:48] <jhutz> I asked why "import" should be _immediately_ after require, as opposed to merely after
[17:16:46] <kdz> cyrus: imports should be one place
[17:18:20] <kdz> jh: we should address from the view of global v. local scope
[17:18:40] <kjetilho> "global" means you can see variables from parent, even though you may not want to
[17:19:23] <kjetilho> "export" is only global to the current script, and children
[17:19:43] <hardie@jabber.psg.com> cookies in one
[17:20:09] <kdz> COOKIE!
[17:20:10] <Barry Leiba> Time, gentlemen, please!
[17:20:20] --- hardie@jabber.psg.com has left
[17:20:34] * Barry Leiba has changed the subject to: Sieve session at IETF 66, working overtime
[17:20:53] --- kdz has left
[17:21:53] * Barry Leiba has changed the subject to:
[17:22:01] * Barry Leiba has changed the subject to: Done
[17:22:05] --- Barry Leiba has left
[17:22:19] --- cyrus_daboo has left
[17:24:11] --- stpeter has left
[17:24:12] --- jhutz has left
[17:24:36] <kjetilho> I'm not sure if we need the restriction that imported variables can't be reexported
[17:25:47] --- Randall Gellens has left
[17:27:33] --- alexeymelnikov has left
[17:30:55] --- Chris Newman has left
[17:30:58] --- tonyhansen has left
[18:05:32] --- pguenther has left
[19:50:58] --- kjetilho has left