Sieve Working Group notes WORKING GROUP STATUS -- 5228, 5229, 5230, 523, 5232, 5233, 5235 gone to RFC - IN the queue -- Notify, Notify-XMPP --- blocked on Sieve notify mailto - Cyrus: Where do we want the working group to go? Do we want to proceed to taking Sieve to draft status? What interest is there in the working group to do this? Key things: implementation and interoperability report. Questions around what exactly that means in the case of sieve. How do we define interoperability? Comments in response: - conformance tests test whether programs process sieve correctly, not whether they are generated - Server implementations which process scripts process it the same way is one definition of interoperability; when you run a sieve script, this is what's done - Sieve is instructions on how to handle messages, interoperability means if you have two parties one generating the other interpreting a script, they get the same meaning Comment from chair: transport isn't within scope, we note - specification is supposed to be a meeting point in the center - Sieve isn't a protocol, it's a language, so it cannot be judged by protocol standards - how do you judge the intent of the person who wrote the script? The only way to judge interoperability is to look at what different implementations do with the same script. Cannot judge with respect to intent of writer. -- yes, with a language there are always various ways of achieving the same thing - in protocol testing, it's the interaction between client and server; perhaps the right approach is, can you come up with two implementations that process the same script and do basically the same thing with it? I don't want us seeing test suites and deciding the compliance issue based on how many implementations pass this. - spec should be good enough that two implementers read the spec and interpret it the same way, that's the test; independent implementation is tricky because if we discuss it among two implementers, it becomes a collaboration that belies a potential problem with the spec - what we're really talking about is portability of Sieve scripts; part of the confusion is that sieve operates at multiple different points, and at different points, the script interactions are going to be different. Each point has different expectations for portability. - what value does Sieve get from being progressed on standards track, as opposed to being left where it is? - answer: the theory is that there is value generated from going through the process, with respect to validating the spec - while raw mechanical date of documenting steps of interop needs to be satisfied, there is a broader requirement for a document that discusses the state of affairs of current and potential use of sieve (including limitations) for the intent of spreading to industry awareness the state with intent of promoting it -- serving marketing function, as it were, of the process to standard Chair: note that this is part of reworking charter of working group, so table the discussion to that part of the agenda: Chair: summarize: Two possible work items: (1)there is interest in a tool or set of data that will allow us to test strict portability across different sieve implementations Doing that is a first step before an implementation report; (2)Also interest in a second document as an implementation guide to sieve. This would be an elaboration of detail on the current architecture document. NOTIFY MAIL-TO - Barry and Alexey getting Ned's comments updated -- recommendation to keep received line away from the original message -- but pushback from Ned: classify the at-submitted field as a trace field and required that it appears above the copied Received fields as a sort of boundary between the old set of Received Fields and the new. -- From Ned: need a boundary separator - if we do keep received lines, we need one -- so the wording should be if this is the case, must have boundary separator -- auto-submit is already described in passing in email autoreply spec, which makes extensions awkward -- let's remember that mail loops are what help up the base spec for so long -- we will be the first extension to create a parameter for auto-submitted - so we need to create the registry - received headers seems to work well because firewalls, etc. tend to allow received headers through, but if stripped can't rely on them, if reliance here makes document too complicated for one document - something can go out and come back in with auto-submit stripped out, what do you do then? - main question discussed last time about mail loop that will satisfy IESG that there's enough discussion and advice for implementers about mail loop detection - we need advice from IESG about what this will be. - what do we need, an extra paragraph on security about what auto-submit is and how the mail loop issue should be addressed? - answer: we need a line about security considerations that points to section -- add a parameter to auto-submitted that can be used ot identify the email address of the owner of the Sieve script generating the notification --- is this a should or a must? -- is the value from From: header field sufficient for tracking notification origin? --- comment, yes is sufficient --- maybe add an optional parameter, but specify the use of it with keyword --- one way to finesse the issue is to define two parameters, one for actual address, the other for a token to be used by an admin to an actual user -- mailfrom most reliable way of avoiding mail loops, require it be set in a deterministic way --- but mailfrom that is empty will break, bounce loops, etc. --- but if you have a mailfrom that's used in more than one script, you lose the ability to uniquely identify which script triggered it -- Procedural - if the new parameter to auto-submitted: is needed - in which document should it be refined? ---- Consensus on what should be done, Barry will write text, has clear guidance on received headers, starting point for auto-submitted ---- We all really need to review the -06 draft!!! REJECT/REFUSE - normative reference to 2033 bad, because 2033 is Informative. Need to ask an exception. - text in intro is misleading, ereject action doesn't always result in protocol level rejection -- draft presents ereject as a solution to blowback problem which is an overstatement ---- that reject isn't appropriate to use when you're sure you're dealing with spam, since you cannot count on it works at the SMTP level. - different errors from different users isn't an issue, based on whether you can or cannot do early evaluation -- sure in a DSN multiple errors aren't a problem, but what if all recipients reject with different errors? Do we really want a DSN in this case or should we send some generic message instead? -- case might be that implementations might send back several different responses - Recommendations about use of 8 bit responses wouldn't work for some cases --- Ned doesn't think this is worth fixing as the use case when this breaks is uncommon (passthrough MTA) MIME LOOPS -- current draft -04 addressed most comments from working group, but not all -- not done - a number of substantive changes including fundamental changes to syntax documenting rewrite/reordering -- at this point, we should review the current specification --- review of mail message from Arnt Gulbrandsen 1. [missed discussion on 1] 2. wouldn't it be better to tie break and its loop explicitly, eg with an identifier, the identifier would be optional on the loop and mandatory on the break. -- disagreement on mandatory during the break -- weak consensus in room to do that change - Open Issue: behavior of break BODY IESG COMMENTS -- question about scope of wildcards (Tim Polk discussion) what were implications when wildcard put into body -- wrt body-07 -- Tim now thinks it's a red herring, what he does want to be sure is that any implementation, where different systems using different sets of code, wants to be sure sieve scripts work the same way, if wildcarding is unconstrained, wants something to say behavior is consistent across implementations; if context is clear, it should be stated. Consistency of implementation via a one or two sentence change in the wording. ---original issue, is there an actual issue with length of backtracking each implementation does? ---- we do allow implementations to impost limits on such things, we are unlikely t allow body :matches for exactly this reason -- interpretation of document read raw is different from sense of room, so it's a straightforward attempt to make this abundantly clear in draft - issues related to multiline strings and how matching works on them, especially when using regex instead of pattern matching, cf. perl re man page, covers these issues - unicode consortium has a technical working paper on regex matching - also TCL regexp description EDITHEADER - see chair's comments INDIVIDUAL SUBMISSIONS - seven on list - Lisa - "working group doesn't have enough participation level to bring a bunch more drafts through to standardization" - thinks WG out of question, work can be done as individual submissions, BUT individual submissions replacing working group documents on standards track is something we need to be careful about; suggests considering Informational as approach as having lower barriers to process -- comment flap over base spec has killed the energy of this group -- information is not an option for sieve extension, I believe experimental and standards track are the only allowed choices -- problem with informational is it restricts normative reference in standards document --- that can become optionally overcome with an exception -- but not normal -- pushback on the issue of energy -- question is IESG more reluctant to do individual submissions - answer yes, but this is not absolute - individual submissions can still be considered group standard - not easy though and late binding changes are difficult, so IESG will look at them quite individual -- NO, it does not, it does not take the pressure off when there are restrictions on what can be published as an extension to an existing protocol --- Lisa, we can assist to make a lower barrier here -- comment individual submission are often the best way to advance a non-controversial document, don't always need a full working group for it; if it's workload for Area Director that's an issue, can help to demonstrate wider support by asking to find somebody in WG as a document shepherd, but to say you have a higher barrier for individual submissions is a real problem unless you're going to have really long-lived working groups - Lisa, her preferences and IESG preferences are different, says as author of individual submissions, but "lack of objection" is no longer seen as a working consensus. -- should charter contain text as to nature and extent of review of individual submissions? - comment that Sieve started out as an individual submission -- question to recharter to add these other documents? - reality is a lot of the documents are actually finished, from a process standpoint it seems silly to add them to the charter if they're just ready to go -- at least one individual submission has made it to full standard, SMTP Pipelining --- those are older cases, though [suggestion circumstances have changed] - working group can offer an opinion about the contentiousness of a given document, even for an individual submission - Lisa - warn that they won't all sail through, and that's not necessarily a comment on document quality -- will advice from working group on individual documents help? - yes and no [[[--- detailed discussion about individual submissions ensues]]] -- suggestion that given this attitude from IESG we just update the charter --- but chair indicates may not be able to take all 7 -- if you shut down a WG with low participation, you get NO participation -- suggestion for IESG plenary - chair tables further discussion so we can complete agenda - this discussion counts towards discussion of charter review 8-) - Chris: keeping WG open and processing these as WG documents WILL be simpler process to getting this done; avoid questions about end-running the process for each and every document, if WG stays open the documents flow through the system -- would there be pushback from IESG on rechartering and adding the items? (1) imapext-metadata-03 Accessing IMAP per mailbox annotations from Sieve Alexey needs more reviews - Barry volunteers to review - Cyrus will as well -- metadata has to get progressed first - no, metadata describes the model, this extension doesn't require IMAP metadata be implemented - question about metadata on the charter, no consensus about that - comment about difficulty to implementation, echoed by another person (2) IMAP Sieve (imap-sieve-04) -- Not necessarily a part of the lemonade group work. -- we should definitely pick up under rechartering if Lemonade doesn't take it. (3) Sieve Drafts (sieve-environment-02) [refer to slides Ned submitted] - open issues -- is initial set of items complete and correct? --- yes, consensus -- is registration model for environment items correct? --- general issue of whether any protocol should have vendor-specific registration spaces ---- comment from Chris: current structure for registry left up to participants. As a technical participant, I like registries with multiple facets, covers multiple areas of potential contention. --- Ned I could put in text saying that groups of extensions should have a common "name." prefix. --- agreement in room (4) sieve-ihave-01 - has been reviewed, ready for last call, important for implementations with extensions - consensus in room (5) sieve-date-index-08 - updated draft with minor changes - ready for last call, chair agrees, room agrees -- one oddball thing...description of interaction of header and index, if do test with multiple headers, why was this done? -- suggestion question posted to list, we are running out of time (6) sieve in xml-01 - open issues -- representation of comments in XML --- the problem with not using XML comments is that there are schema issues with allowing a element everywhere. -- relax NG grammar --- Ned, perhaps those schema issues with would go away with Relax NG -- that's the sort of thing Relax NG fixes. --- I think they probably do, but then we have a schema that cannot be represented in XML Schema. ---XML processors are permitted to arbitrarily ignore XML comments, so a Sieve with comments wouldn't round-trip if XML comments were used. -- perl sieve to XML converter (7) SIP Notify Method sip-message-01 -- need comments from SIP experts RECHARTER OF WG DISCUSSION (Official, see above for earlier discussion points - MW) -- hand-raising in room, willingness to review documents -- yes, 7 or 8 hands in air -- consensus by humming to recharter the working group -- there was also humming on IM -- but not all documents on the list will go on, discussion about this on the mailing list - who is working on implementation guide? -- suggestion it may be too contentious to put on WG charter, also not central to work, could be good for outside document as individual submission that would be good for group as a whole to shepherd through informally - last point taking Sieve to standard, do we keep that in charter, and start in test suite work? - also MANAGESIEVE issue, Out of time, leave questions to discussion on the list, with an eye towards a charter revision proposal. Another question, is interest in participation in Dublin interop