headers
Wolfgang Segmuller | 3 Jul 2001 20:47
Picon
Favicon

Notify extension to Sieve


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
Permalink | Reply | 4 comments |
headers
Simon Josefsson | 3 Jul 2001 21:57

Re: Notify extension to Sieve


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 <at> bar (foo bar) rather than "foo bar" <foo <at> 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 <at> watson.ibm.com> writes:

> Abstract
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nigel Swinson | 4 Jul 2001 14:24

Re: Notify extension to Sieve


> 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
Permalink | Reply | 0 comments |
headers
Tony Hansen | 5 Jul 2001 20:32
Picon
Favicon

Re: Notify extension to Sieve


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 <at> 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
Permalink | Reply | 0 comments |
headers
ned.freed | 13 Jul 2001 17:21

Re: Notify extension to Sieve


> 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 <at> bar (foo bar) rather than "foo bar" <foo <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
tmartin | 14 Jul 2001 01:56

Re: Notify extension to Sieve


Excerpts From ned.freed <at> 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
Permalink | Reply | 752 comments |
headers
Nigel Swinson | 14 Jul 2001 14:13

Re: Notify extension to Sieve


> >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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Hansen | 14 Jul 2001 23:40
Picon
Favicon

Re: Notify extension to Sieve


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 <at> 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).
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Segmuller | 16 Jul 2001 16:39
Picon
Favicon

Re: Notify extension to Sieve


"Nigel Swinson" <Nigel <at> 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 <at> 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 <at> 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
(Continue reading)

Permalink | Reply | 751 comments |

Gmane