Re: Notify extension to Sieve
Wolfgang Segmuller <whs@watson.ibm.com> Mon, 16 July 2001 14:39 UTC
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GEdLL13681 for ietf-mta-filters-bks; Mon, 16 Jul 2001 07:39:21 -0700 (PDT)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GEdJq13677 for <ietf-mta-filters@imc.org>; Mon, 16 Jul 2001 07:39:19 -0700 (PDT)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6GEdE712686; Mon, 16 Jul 2001 10:39:15 -0400
Received: from ballybran.diz.watson.ibm.com (ballybran.watson.ibm.com [9.2.43.185]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id KAA12320; Mon, 16 Jul 2001 10:39:14 -0400
Date: Mon, 16 Jul 2001 10:39:11 -0400
From: Wolfgang Segmuller <whs@watson.ibm.com>
To: tmartin@mirapoint.com, ietf-mta-filters@imc.org
Subject: Re: Notify extension to Sieve
Message-ID: <3142505723.995279951@ballybran.diz.watson.ibm.com>
In-Reply-To: <200107132356.ADQ00441@mail.mirapoint.com>
X-Mailer: Mulberry/2.0.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
"Nigel Swinson" <Nigel@Swinson.com> wrote: > > On the other hand if we want to just rely on "implementations MAY shorten > the message for technical or aesthetic reasons" then I think that > $text[n]$ > would be better as n lines, as lines are always \n, and therefore easy to > find and convert as a onner, as opposed to finding character boundaries > in > variable byte-to-character charsets like UTF8. > <tmartin@mirapoint.com> wrote: > This is a good point. Trying to deal with byte boundrys with different > character sets is a major pain. I agree the output should be utf8 and the > 'n' in text[n] should refer to n unicode characters not n octets (as > currently implied). I agree that UTF-8 should be used as the output charset and text[n] refers to unicode chars. Maybe we should highlight that an implementation MAY shorten the message because some notification mechanisms have limited capabilities. Simon Josefsson <jas@extundo.com> wrote: > * I would be happier with two separate variables for the RFC 2822 > "display name" and the "address". Having both the name and the mail > address would fill up my entire cell phone display. Maybe keep > $from$ as is, and add $from-address$ and $from-name$. > > Q: Is it intended to exclude legacy address forms by using the term > "display name"? Perhaps no parsing of From: was intended. I.e.: > foo@bar (foo bar) rather than "foo bar" <foo@bar>. > My idea was that $from$ would be either display name or email address. But I can see we need $from-address$ and $from-name$ also. An implementation MUST support the RFC 2822 definition of display name. An implementation MAY support legacy address forms. Should there be a default value for $from-name$ if none was found? Possibly $from-address$. > > * Security consideration additions: > > The risk of creating mail loops must be considered, many instant > messaging systems (e.g. ICQ) have capabilities to forward the > notification by Internet Mail if you're not online. Unless somehow > prevented, this might easily cause huge workload for the servers > involved. > Yes, we must add this. > > * Is the draft really copyright 1999? :) There are some control > characters (^M) in it as well. Also perhaps update RFC 82{1,2} -> > RFC 282{1,2}. > Tony Hansen <tony@att.com> wrote: > Shouldn't we be able to specify the address of the recipient, using an > IM URL, as being defined in the IMPP working group? Also, how is it > identified who the IM is coming from? The exact format of the recipient of the notification would be determined by the implementation. The use of an IM URL for IM notifications is a good idea, but this document deals with a notification frame work, not with an individual notification mechanism. The originator of an IM would be implementation defined. A possible value could be an ID dedicated to the sieve notify processor. ned.freed@mrochek.com wrote: > I agree that multiple variables of this sort are a good idea. > Additionally, > there probably needs to be some defensive text about not using Sender:, > Resent-From:, and Reply-to: fields here. I agree about the defensive text. > One way to address this would be to allow implementations to ignore > notification requests based on a telltale indicator that the message > is itself a notification. > Yes, this must be added > > There's also the issue of denotify support. Plenty of notification > schemes don't have the concept of undoing a notification. So it has > to be clear that it is legal for denotification to be a no-op. > The denotify MUST be handled by the Sieve engine. The sieve engine must already hold the notifications to see which ones actually get sent based on priority. Wolfgang Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6GEdLL13681 for ietf-mta-filters-bks; Mon, 16 Jul 2001 07:39:21 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GEdJq13677 for <ietf-mta-filters@imc.org>; Mon, 16 Jul 2001 07:39:19 -0700 (PDT) Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f6GEdE712686; Mon, 16 Jul 2001 10:39:15 -0400 Received: from ballybran.diz.watson.ibm.com (ballybran.watson.ibm.com [9.2.43.185]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id KAA12320; Mon, 16 Jul 2001 10:39:14 -0400 Date: Mon, 16 Jul 2001 10:39:11 -0400 From: Wolfgang Segmuller <whs@watson.ibm.com> To: tmartin@mirapoint.com, ietf-mta-filters@imc.org Subject: Re: Notify extension to Sieve Message-ID: <3142505723.995279951@ballybran.diz.watson.ibm.com> In-Reply-To: <200107132356.ADQ00441@mail.mirapoint.com> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> "Nigel Swinson" <Nigel@Swinson.com> wrote: > > On the other hand if we want to just rely on "implementations MAY shorten > the message for technical or aesthetic reasons" then I think that > $text[n]$ > would be better as n lines, as lines are always \n, and therefore easy to > find and convert as a onner, as opposed to finding character boundaries > in > variable byte-to-character charsets like UTF8. > <tmartin@mirapoint.com> wrote: > This is a good point. Trying to deal with byte boundrys with different > character sets is a major pain. I agree the output should be utf8 and the > 'n' in text[n] should refer to n unicode characters not n octets (as > currently implied). I agree that UTF-8 should be used as the output charset and text[n] refers to unicode chars. Maybe we should highlight that an implementation MAY shorten the message because some notification mechanisms have limited capabilities. Simon Josefsson <jas@extundo.com> wrote: > * I would be happier with two separate variables for the RFC 2822 > "display name" and the "address". Having both the name and the mail > address would fill up my entire cell phone display. Maybe keep > $from$ as is, and add $from-address$ and $from-name$. > > Q: Is it intended to exclude legacy address forms by using the term > "display name"? Perhaps no parsing of From: was intended. I.e.: > foo@bar (foo bar) rather than "foo bar" <foo@bar>. > My idea was that $from$ would be either display name or email address. But I can see we need $from-address$ and $from-name$ also. An implementation MUST support the RFC 2822 definition of display name. An implementation MAY support legacy address forms. Should there be a default value for $from-name$ if none was found? Possibly $from-address$. > > * Security consideration additions: > > The risk of creating mail loops must be considered, many instant > messaging systems (e.g. ICQ) have capabilities to forward the > notification by Internet Mail if you're not online. Unless somehow > prevented, this might easily cause huge workload for the servers > involved. > Yes, we must add this. > > * Is the draft really copyright 1999? :) There are some control > characters (^M) in it as well. Also perhaps update RFC 82{1,2} -> > RFC 282{1,2}. > Tony Hansen <tony@att.com> wrote: > Shouldn't we be able to specify the address of the recipient, using an > IM URL, as being defined in the IMPP working group? Also, how is it > identified who the IM is coming from? The exact format of the recipient of the notification would be determined by the implementation. The use of an IM URL for IM notifications is a good idea, but this document deals with a notification frame work, not with an individual notification mechanism. The originator of an IM would be implementation defined. A possible value could be an ID dedicated to the sieve notify processor. ned.freed@mrochek.com wrote: > I agree that multiple variables of this sort are a good idea. > Additionally, > there probably needs to be some defensive text about not using Sender:, > Resent-From:, and Reply-to: fields here. I agree about the defensive text. > One way to address this would be to allow implementations to ignore > notification requests based on a telltale indicator that the message > is itself a notification. > Yes, this must be added > > There's also the issue of denotify support. Plenty of notification > schemes don't have the concept of undoing a notification. So it has > to be clear that it is legal for denotification to be a no-op. > The denotify MUST be handled by the Sieve engine. The sieve engine must already hold the notifications to see which ones actually get sent based on priority. Wolfgang Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ELeiJ11311 for ietf-mta-filters-bks; Sat, 14 Jul 2001 14:40:44 -0700 (PDT) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ELegq11307 for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2001 14:40:42 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f6ELedg19655 for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2001 17:40:39 -0400 (EDT) Received: from att.com ([135.210.112.13]) by maillennium.att.com (labmail) with SMTP id <20010714214036099001ec8ge> (Authid: tony@maillennium.att.com); Sat, 14 Jul 2001 21:40:37 +0000 Message-ID: <3B50BC63.9CBAA4E2@att.com> Date: Sat, 14 Jul 2001 17:40:51 -0400 From: Tony Hansen <tony@att.com> X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-mta-filters@imc.org Subject: Re: Notify extension to Sieve References: <200107132356.ADQ00441@mail.mirapoint.com> <004601c10c5e$76b929b0$9a3c30d5@nigel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Simple solution to text[n] possibly not ending in a CRLF: It includes the first n-2 characters followed by a CRLF. Also, I think most SMS device length maximums are defined in terms of bytes, not characters. Tony Hansen tony@att.com Nigel Swinson wrote: > > > >The text[n] construct is also fairly problematic. For example, what > happens > > >when the cut off falls in the middle of a line terminator? What happen > when th > > >e > > >number fall in the middle of a multibyte character? > > > > > >A line-oriented construct would avoid these issues, however, it wouldn't > > >necessarily work right with message services that have limited text > capacity. > > > > > > This is a good point. Trying to deal with byte boundrys with different > character sets is a major pain. I agree the output should be utf8 and the > 'n' in text[n] should refer to n unicode characters not n octets (as > currently implied). > > > > btw Thank you to everyone for the comments in the last couple messages. > We'll try to get them integrated and a new version out in the near future. > > > > If there are going to be message services that have a limited text capacity, > then if we treat n as "n unicode characters", but then convert the "n > unicode characters" to utf8, then we have no accurate way of determining in > advance the size of the utf-8 string. > > My Utf8 is a little rusty, but a character can end up as from 1 to 6 bytes, > so our output buffer may actually require to be anything from n to 6n bytes. > > If we are to use UTF8, which I agree is a good idea, then perhaps we need > some kind of clause that protects the output buffer from being greater than > a certain limit while maintaining character boundaries? > > Perhaps: > > $text[n]$ - as many characters of the first text/* part, encoded as UTF8, > that will fit in an n byte buffer. > > (Yuck?!) > > Or maybe change the text[n] parameter to max-message-size[n] that is the > maximum size that the COMPLETE message can be where the message size > includes $from, $env-from$, $text$ etc. This way you would specify how much > data you wanted to recieve, then just use the $text$ paramter and the system > will put as much UTF8 message data into the output message buffer as > possible. The system MUST ensure that truncated messages are truncated at > the start of a character boundary. > > On the other hand if we want to just rely on "implementations MAY shorten > the message for technical or aesthetic reasons" then I think that $text[n]$ > would be better as n lines, as lines are always \n, and therefore easy to > find and convert as a onner, as opposed to finding character boundaries in > variable byte-to-character charsets like UTF8. > > Incidentally if "implementations MAY shorten the message for technical or > aesthetic reasons", then we ought to say "Where they do, they MUST truncate > the message before a character boundary". > > Just some ideas, I have little experience of the kinds of system that are > going to recieve these notifications... > > As a side note, in the following examples from section 3.1, aren't they > missing a ":message": > > require ["notify","fileinto"]; > > if header :contains "from" "boss@example.org" { > notify :high "This is probably very important"; > } > > if header :contains "to" "sievemailinglist@example.org" { > notify :low "[SIEVE] $from$: $subject$"; > fileinto "INBOX.sieve"; > } > > And also in section 3.1 shouldn't it be ":message" not "message:" ? > > Syntax: notify [":method" string] > [":id" string] > [":options" 1*(string-list / number)] > [<":low" / ":normal" / ":high">] > ["message:" string] > > Nigel Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6ECIsM23934 for ietf-mta-filters-bks; Sat, 14 Jul 2001 05:18:54 -0700 (PDT) Received: from rock1.rockliffe.com (rockliffe.com [64.14.3.246]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ECIrq23930 for <ietf-mta-filters@imc.org>; Sat, 14 Jul 2001 05:18:53 -0700 (PDT) Received: from nigel (usr177-dun1.cableinet.co.uk [213.48.60.154]) by rock1.rockliffe.com (Rockliffe SMTPRA 4.5.4) with ESMTP id <B0001055759@rock1.rockliffe.com>; Sat, 14 Jul 2001 05:17:27 -0700 Message-ID: <004601c10c5e$76b929b0$9a3c30d5@nigel> From: "Nigel Swinson" <Nigel@Swinson.com> To: <tmartin@mirapoint.com>, <ietf-mta-filters@imc.org> References: <200107132356.ADQ00441@mail.mirapoint.com> Subject: Re: Notify extension to Sieve Date: Sat, 14 Jul 2001 13:13:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > >The text[n] construct is also fairly problematic. For example, what happens > >when the cut off falls in the middle of a line terminator? What happen when th > >e > >number fall in the middle of a multibyte character? > > > >A line-oriented construct would avoid these issues, however, it wouldn't > >necessarily work right with message services that have limited text capacity. > > > This is a good point. Trying to deal with byte boundrys with different character sets is a major pain. I agree the output should be utf8 and the 'n' in text[n] should refer to n unicode characters not n octets (as currently implied). > > btw Thank you to everyone for the comments in the last couple messages. We'll try to get them integrated and a new version out in the near future. > If there are going to be message services that have a limited text capacity, then if we treat n as "n unicode characters", but then convert the "n unicode characters" to utf8, then we have no accurate way of determining in advance the size of the utf-8 string. My Utf8 is a little rusty, but a character can end up as from 1 to 6 bytes, so our output buffer may actually require to be anything from n to 6n bytes. If we are to use UTF8, which I agree is a good idea, then perhaps we need some kind of clause that protects the output buffer from being greater than a certain limit while maintaining character boundaries? Perhaps: $text[n]$ - as many characters of the first text/* part, encoded as UTF8, that will fit in an n byte buffer. (Yuck?!) Or maybe change the text[n] parameter to max-message-size[n] that is the maximum size that the COMPLETE message can be where the message size includes $from, $env-from$, $text$ etc. This way you would specify how much data you wanted to recieve, then just use the $text$ paramter and the system will put as much UTF8 message data into the output message buffer as possible. The system MUST ensure that truncated messages are truncated at the start of a character boundary. On the other hand if we want to just rely on "implementations MAY shorten the message for technical or aesthetic reasons" then I think that $text[n]$ would be better as n lines, as lines are always \n, and therefore easy to find and convert as a onner, as opposed to finding character boundaries in variable byte-to-character charsets like UTF8. Incidentally if "implementations MAY shorten the message for technical or aesthetic reasons", then we ought to say "Where they do, they MUST truncate the message before a character boundary". Just some ideas, I have little experience of the kinds of system that are going to recieve these notifications... As a side note, in the following examples from section 3.1, aren't they missing a ":message": require ["notify","fileinto"]; if header :contains "from" "boss@example.org" { notify :high "This is probably very important"; } if header :contains "to" "sievemailinglist@example.org" { notify :low "[SIEVE] $from$: $subject$"; fileinto "INBOX.sieve"; } And also in section 3.1 shouldn't it be ":message" not "message:" ? Syntax: notify [":method" string] [":id" string] [":options" 1*(string-list / number)] [<":low" / ":normal" / ":high">] ["message:" string] Nigel Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6E00la07297 for ietf-mta-filters-bks; Fri, 13 Jul 2001 17:00:47 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [63.107.133.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6E00jq07293 for <ietf-mta-filters@imc.org>; Fri, 13 Jul 2001 17:00:45 -0700 (PDT) Received: from margot.mirapoint.com (margot.mirapoint.com [192.168.1.178]) by mail.mirapoint.com (Mirapoint) with ESMTP id ADQ00441; Fri, 13 Jul 2001 16:56:16 -0700 (PDT) Date: Fri, 13 Jul 2001 16:56:16 -0700 (PDT) From: <tmartin@mirapoint.com> Message-Id: <200107132356.ADQ00441@mail.mirapoint.com> To: jas@extundo.com, ned.freed@mrochek.com, whs@watson.ibm.com, ietf-mta-filters@imc.org Subject: Re: Notify extension to Sieve Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Excerpts From ned.freed@mrochek.com: Message >There's also the whole issue of encoded-words and character sets. I think the >way to go is for this document to be clear that the notification material it >creates is in UTF-8, and that encoded-word and content decoding should be done > >as part of these substitution operations. > >The text[n] construct is also fairly problematic. For example, what happens >when the cut off falls in the middle of a line terminator? What happen when th >e >number fall in the middle of a multibyte character? > >A line-oriented construct would avoid these issues, however, it wouldn't >necessarily work right with message services that have limited text capacity. This is a good point. Trying to deal with byte boundrys with different character sets is a major pain. I agree the output should be utf8 and the 'n' in text[n] should refer to n unicode characters not n octets (as currently implied). btw Thank you to everyone for the comments in the last couple messages. We'll try to get them integrated and a new version out in the near future. Thanks, Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f6DFffw25931 for ietf-mta-filters-bks; Fri, 13 Jul 2001 08:41:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DFfdq25920 for <ietf-mta-filters@imc.org>; Fri, 13 Jul 2001 08:41:39 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01K5UWQUKFTC000MS8@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 13 Jul 2001 08:41:35 -0700 (PDT) Date: Fri, 13 Jul 2001 08:21:09 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: Notify extension to Sieve In-reply-to: "Your message dated Tue, 03 Jul 2001 21:57:15 +0200" <ilu8zi5yeec.fsf@barbar.josefsson.org> To: Simon Josefsson <jas@extundo.com> Cc: Wolfgang Segmuller <whs@watson.ibm.com>, ietf-mta-filters@imc.org Message-id: <01K5VK0RT1AG000MS8@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <2034209321.994171654@ballybran.diz.watson.ibm.com> <2034209321.994171654@ballybran.diz.watson.ibm.com> Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > This looks cool! Some random questions/suggestions from a bystander: I agree that this is work that should be pursued. > * I would be happier with two separate variables for the RFC 2822 > "display name" and the "address". Having both the name and the mail > address would fill up my entire cell phone display. Maybe keep > $from$ as is, and add $from-address$ and $from-name$. I agree that multiple variables of this sort are a good idea. Additionally, there probably needs to be some defensive text about not using Sender:, Resent-From:, and Reply-to: fields here. > Q: Is it intended to exclude legacy address forms by using the term > "display name"? Perhaps no parsing of From: was intended. I.e.: > foo@bar (foo bar) rather than "foo bar" <foo@bar>. More generally, "display name" is RFC 2822 terminology, not RFC 822 terminology. We know from experience that if you leave this unspecified people will do odd things like use comment suffixes rather than a prefix phrase and other gross things. I think the way to go at this point is to not try to support all the legacy stuff. So the reference needs to be to RFC 2822, not RFC 822, and it needs to be clear that "display name" is a clearly defined construct there. > * Are $subject$, $text$ etc QP/CTE-decoded? There's also the whole issue of encoded-words and character sets. I think the way to go is for this document to be clear that the notification material it creates is in UTF-8, and that encoded-word and content decoding should be done as part of these substitution operations. The text[n] construct is also fairly problematic. For example, what happens when the cut off falls in the middle of a line terminator? What happen when the number fall in the middle of a multibyte character? A line-oriented construct would avoid these issues, however, it wouldn't necessarily work right with message services that have limited text capacity. > * Security consideration additions: > The risk of creating mail loops must be considered, many instant > messaging systems (e.g. ICQ) have capabilities to forward the > notification by Internet Mail if you're not online. Unless somehow > prevented, this might easily cause huge workload for the servers > involved. One way to address this would be to allow implementations to ignore notification requests based on a telltale indicator that the message is itself a notification. There's also the issue of denotify support. Plenty of notification schemes don't have the concept of undoing a notification. So it has to be clear that it is legal for denotification to be a no-op. > * Is the draft really copyright 1999? :) There are some control > characters (^M) in it as well. Also perhaps update RFC 82{1,2} -> > RFC 282{1,2}. And add the various documents cited to the bibliography. Ned Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f65IW1q20652 for ietf-mta-filters-bks; Thu, 5 Jul 2001 11:32:01 -0700 (PDT) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65IVxm20645 for <ietf-mta-filters@imc.org>; Thu, 5 Jul 2001 11:31:59 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f65IVqW04558 for <ietf-mta-filters@imc.org>; Thu, 5 Jul 2001 14:31:56 -0400 (EDT) Received: from att.com ([135.197.90.112]) by maillennium.att.com (labmail) with SMTP id <20010705183151099001ecvbe> (Authid: tony@maillennium.att.com); Thu, 5 Jul 2001 18:31:52 +0000 Message-ID: <3B44B2C0.4176C362@att.com> Date: Thu, 05 Jul 2001 14:32:32 -0400 From: Tony Hansen <tony@att.com> X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Wolfgang Segmuller <whs@watson.ibm.com> CC: ietf-mta-filters@imc.org Subject: Re: Notify extension to Sieve References: <2034209321.994171654@ballybran.diz.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Shouldn't we be able to specify the address of the recipient, using an IM URL, as being defined in the IMPP working group? Also, how is it identified who the IM is coming from? Tony Hansen tony@att.com Wolfgang Segmuller wrote: > > Abstract > > Users go to great lengths to be notified as quickly as possible that > they have received new mail. Most of these methods involve polling > to check for new messages periodically. A push method handled by the > final delivery agent gives users quicker notifications and saves > server resources. This document does not specify the notification > method but is expected that using existing instant messaging > infrastructure such as Zephyr, ICQ, or SMS messages will be popular. > This draft describes an extension to the Sieve mail filtering > language that allows users to give specific preferences for > notification of Sieve actions. > > http://www.ietf.org/internet-drafts/draft-martin-sieve-notify-01.txt > > Wolfgang Segmuller Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f64CO9r23214 for ietf-mta-filters-bks; Wed, 4 Jul 2001 05:24:09 -0700 (PDT) Received: from rock1.rockliffe.com (rockliffe.com [64.14.3.246]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f64CO7m23210 for <ietf-mta-filters@imc.org>; Wed, 4 Jul 2001 05:24:07 -0700 (PDT) Received: from nige (NIGE.rockliffe.com [129.215.200.115]) by rock1.rockliffe.com (Rockliffe SMTPRA 4.5.4) with ESMTP id <B0001040178@rock1.rockliffe.com>; Wed, 4 Jul 2001 05:22:42 -0700 Message-ID: <03bf01c10484$36002d60$73c8d781@enterprise.ucs.ed.ac.uk> From: "Nigel Swinson" <Nigel@Swinson.com> To: "Wolfgang Segmuller" <whs@watson.ibm.com>, "Simon Josefsson" <jas@extundo.com> Cc: <ietf-mta-filters@imc.org> References: <2034209321.994171654@ballybran.diz.watson.ibm.com> <ilu8zi5yeec.fsf@barbar.josefsson.org> Subject: Re: Notify extension to Sieve Date: Wed, 4 Jul 2001 13:24:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f64CO7m23211 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> > This looks cool! Some random questions/suggestions from a bystander: I agree. I'd use such an extension... if I had a mobile phone... which I don't. :o) > * I would be happier with two separate variables for the RFC 2822 > "display name" and the "address". Having both the name and the mail > address would fill up my entire cell phone display. Maybe keep > $from$ as is, and add $from-address$ and $from-name$. I'd also like to see this addition. This is the kind of thing that irritates you every single time you use a feature, and wish someone had implemented. It's like all those computer games with 60 second movies between levels that you watch about 200 times and end up wishing it wasn't there in the first place! I recon you are most interested in $from-name$ and $subject$ and slightly interested in $from-address$. Mobile phones make for crappy mail clients at the moment, so they aren't all that much use for lots of $text$, but I suppose you would typically use $text$ so that you could read the message if you wanted to. Nigel Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Juh127436 for ietf-mta-filters-bks; Tue, 3 Jul 2001 12:56:43 -0700 (PDT) Received: from dolk.extundo.com (dolk.extundo.com [195.42.214.242]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Juem27432 for <ietf-mta-filters@imc.org>; Tue, 3 Jul 2001 12:56:41 -0700 (PDT) Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f63Junq09324; Tue, 3 Jul 2001 21:56:50 +0200 To: Wolfgang Segmuller <whs@watson.ibm.com> Cc: ietf-mta-filters@imc.org Subject: Re: Notify extension to Sieve References: <2034209321.994171654@ballybran.diz.watson.ibm.com> From: Simon Josefsson <jas@extundo.com> In-Reply-To: <2034209321.994171654@ballybran.diz.watson.ibm.com> (Wolfgang Segmuller's message of "Tue, 03 Jul 2001 14:47:34 -0400") Date: Tue, 03 Jul 2001 21:57:15 +0200 Message-ID: <ilu8zi5yeec.fsf@barbar.josefsson.org> Lines: 44 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> This looks cool! Some random questions/suggestions from a bystander: * I would be happier with two separate variables for the RFC 2822 "display name" and the "address". Having both the name and the mail address would fill up my entire cell phone display. Maybe keep $from$ as is, and add $from-address$ and $from-name$. Q: Is it intended to exclude legacy address forms by using the term "display name"? Perhaps no parsing of From: was intended. I.e.: foo@bar (foo bar) rather than "foo bar" <foo@bar>. * Are $subject$, $text$ etc QP/CTE-decoded? * Security consideration additions: The risk of creating mail loops must be considered, many instant messaging systems (e.g. ICQ) have capabilities to forward the notification by Internet Mail if you're not online. Unless somehow prevented, this might easily cause huge workload for the servers involved. * Is the draft really copyright 1999? :) There are some control characters (^M) in it as well. Also perhaps update RFC 82{1,2} -> RFC 282{1,2}. Wolfgang Segmuller <whs@watson.ibm.com> writes: > Abstract > > Users go to great lengths to be notified as quickly as possible that > they have received new mail. Most of these methods involve polling > to check for new messages periodically. A push method handled by the > final delivery agent gives users quicker notifications and saves > server resources. This document does not specify the notification > method but is expected that using existing instant messaging > infrastructure such as Zephyr, ICQ, or SMS messages will be popular. > This draft describes an extension to the Sieve mail filtering > language that allows users to give specific preferences for > notification of Sieve actions. > > > http://www.ietf.org/internet-drafts/draft-martin-sieve-notify-01.txt > > Wolfgang Segmuller Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f63Ilem25578 for ietf-mta-filters-bks; Tue, 3 Jul 2001 11:47:40 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Ilcm25574 for <ietf-mta-filters@imc.org>; Tue, 3 Jul 2001 11:47:39 -0700 (PDT) Received: from sp1n190at0.watson.ibm.com (sp1n190at0.watson.ibm.com [9.2.104.63]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id f63IlZi19634 for <ietf-mta-filters@imc.org>; Tue, 3 Jul 2001 14:47:35 -0400 Received: from ballybran.diz.watson.ibm.com (ballybran.watson.ibm.com [9.2.43.185]) by sp1n190at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id OAA21324 for <ietf-mta-filters@imc.org>; Tue, 3 Jul 2001 14:47:35 -0400 Date: Tue, 03 Jul 2001 14:47:34 -0400 From: Wolfgang Segmuller <whs@watson.ibm.com> To: ietf-mta-filters@imc.org Subject: Notify extension to Sieve Message-ID: <2034209321.994171654@ballybran.diz.watson.ibm.com> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/> List-ID: <ietf-mta-filters.imc.org> List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe> Abstract Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but is expected that using existing instant messaging infrastructure such as Zephyr, ICQ, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific preferences for notification of Sieve actions. http://www.ietf.org/internet-drafts/draft-martin-sieve-notify-01.txt Wolfgang Segmuller
- Notify extension to Sieve Wolfgang Segmuller
- Re: Notify extension to Sieve Simon Josefsson
- Re: Notify extension to Sieve Nigel Swinson
- Re: Notify extension to Sieve Tony Hansen
- Re: Notify extension to Sieve ned.freed
- Re: Notify extension to Sieve tmartin
- Re: Notify extension to Sieve Nigel Swinson
- Re: Notify extension to Sieve Tony Hansen
- Re: Notify extension to Sieve Wolfgang Segmuller