"Nigel Swinson" <Nigel(_at_)Swinson(_dot_)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(_dot_)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(_dot_)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(_at_)bar (foo bar) rather than "foo bar" <foo(_at_)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(_at_)att(_dot_)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(_dot_)freed(_at_)mrochek(_dot_)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