headers
Randall Gellens | 2 Aug 2006 01:26

Review of draft-ietf-sieve-refuse-reject-02


(1) The document should make clear in the Abstract that it is 
updating the existing "Reject" action.

(2) I suggest adding "The message is rejected after end of data" to 
the end of the Abstract.

(3) Typo in Abstract and also Section 1: "updates definition" should 
be "updates the definition".

(4) Suggested change in Section 1: change "sometimes preferable" to 
"generally preferable".

(5) Typos (grammatical errors) in Section 3.1:

Old:
    How message is refused depends
    on capabilities of mail component (MUA, MDA or MTA) executing the
    Sieve script. The Sieve interpreter must do one of the following
    actions, as detailed by the following priority table (items listed
    earlier take precedence). Note that if action can not be taken or
    fails, the interpreter should try the next item in the list:

New:
    How a message is refused depends
    on the capabilities of the mail component (MUA, MDA or MTA) executing the
    Sieve script. The Sieve interpreter must do one of the following
    actions, as detailed by the following priority table (items listed
    earlier take precedence). Note that if an action can not be taken or
    fails, the interpreter should try the next item in the list:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Randall Gellens | 2 Aug 2006 03:49

Review of draft-ietf-sieve-refuse-reject-03


My comments on -02 apply to -03, with one extra:

Is the exacttext option worth it?  It seems to be adding a lot of 
complexity for fairly small gain.  I understand users wanting to put 
reject reasons in their native language.  However, the intent of this 
draft is that reject will operate at the SMTP level wherever 
possible.  Hence, the reject reason should be very short and must be 
usable in an SMTP response.  Use of ASCII is best for 
interoperability.  Use of UTF-8 will only work when EAI extensions 
are also being used, or when MDNs are being generated instead of SMTP 
protocol responses.  Since EAI is new, I don't think we want to rely 
on it.  And the intent is to get away from MDNs.  Hence, we should 
encourage brevity and mandate ASCII.

Once EAI extensions are deployed we can extend reject to permit UTF-8.
--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There are two ways to write error-free programs;
only the third one works.
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 2 Aug 2006 20:18
Favicon

Re: Review of draft-ietf-sieve-refuse-reject-02


Randy, thank you for the comments! I am replying to the easy comments 
first...

Randall Gellens wrote:

> (3) Typo in Abstract and also Section 1: "updates definition" should 
> be "updates the definition".

Fixed.

> (4) Suggested change in Section 1: change "sometimes preferable" to 
> "generally preferable".

Changed.

> (5) Typos (grammatical errors) in Section 3.1:
>
> Old:
>    How message is refused depends
>    on capabilities of mail component (MUA, MDA or MTA) executing the
>    Sieve script. The Sieve interpreter must do one of the following
>    actions, as detailed by the following priority table (items listed
>    earlier take precedence). Note that if action can not be taken or
>    fails, the interpreter should try the next item in the list:
>
> New:
>    How a message is refused depends
>    on the capabilities of the mail component (MUA, MDA or MTA) 
> executing the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randall Gellens | 2 Aug 2006 20:57

Re: Review of draft-ietf-sieve-refuse-reject-02


At 7:18 PM +0100 8/2/06, Alexey Melnikov wrote:

>>  (13) In Section 3.2, should there be any discussion of priority, 
>> for example, if both vacation and reject are attempted, do the 
>> reject and not the vacation?
>
>  reject and vacation are not allowed together, as per section 3.3.

They are not allowed together, but what happens to a script that 
tries it?  Is it a run-time error, or is one of the actions performed 
but not the other?
--

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
It is the business of the future to be dangerous.
Permalink | Reply | 1 comment |
headers
Philip Guenther | 7 Aug 2006 01:06
Favicon

Re: Multiple tagged arguments with the same tag?


On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
...
> okay.  the current draft also says "These next tokens [after the tagged
> argument] may be numbers or strings but they are never blocks."  this
> seems to imply string lists are allowed, but it's not quite clear to me.

For the next revision, I've changed section 2.4 to include string lists as 
literal data and 2.6.2p2 to say "These next tokens may be literal data but 
they are never blocks."

I believe that captures the intent of this discussion, no?

Philip Guenther
Permalink | Reply | 2 comments |
headers
Kjetil Torgrim Homme | 7 Aug 2006 01:19
Picon
Picon

Re: Multiple tagged arguments with the same tag?


On Sun, 2006-08-06 at 16:06 -0700, Philip Guenther wrote:
> On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> ...
> > okay.  the current draft also says "These next tokens [after the tagged
> > argument] may be numbers or strings but they are never blocks."  this
> > seems to imply string lists are allowed, but it's not quite clear to me.
> 
> For the next revision, I've changed section 2.4 to include string lists as 
> literal data and 2.6.2p2 to say "These next tokens may be literal data but 
> they are never blocks."
> 
> I believe that captures the intent of this discussion, no?

sounds good to me, thanks!
--

-- 
Kjetil T.
Permalink | Reply | 1 comment |
headers
Ned Freed | 7 Aug 2006 05:51

Re: Multiple tagged arguments with the same tag?


> On Sun, 2006-08-06 at 16:06 -0700, Philip Guenther wrote:
> > On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> > ...
> > > okay.  the current draft also says "These next tokens [after the tagged
> > > argument] may be numbers or strings but they are never blocks."  this
> > > seems to imply string lists are allowed, but it's not quite clear to me.
> >
> > For the next revision, I've changed section 2.4 to include string lists as
> > literal data and 2.6.2p2 to say "These next tokens may be literal data but
> > they are never blocks."
> >
> > I believe that captures the intent of this discussion, no?

> sounds good to me, thanks!

Me too.

				Ned
Permalink | Reply | 0 comments |
headers
Philip Guenther | 7 Aug 2006 13:47
Favicon

Re: draft-ietf-sieve-3028bis-08.txt


On Tue, 25 Jul 2006, Kjetil Torgrim Homme wrote:
> On Tue, 2006-07-25 at 07:46 -0700, Philip Guenther wrote:
...
>>    to US-ASCII characters.  Strings and comments may contain octets
>>    outside the US-ASCII range.  Specifically, they will normally be in
>>    UTF-8, as specified in [UTF-8].  NUL (US-ASCII 0) is never permitted
>>    in scripts, while CR and LF can only appear as the CRLF line ending.
>
> "normally" isn't good if you can't know if your script is normal or not.

...thus the text I added to 2.4.2 giving examples of when a script might 
include non-UTF-8 text.  Given the exact cases mentioned, I think 
"normally" is a reasonable word to use.  Other email RFCs (1894, 2822, 
3463, 3834, 3898) certainly haven't had problems with using it to describe 
situations where a strict rule can't be drawn but setting the reader's 
expectations is useful.

> I suggest you rephrase it as "Strings and comments may sometimes have a
> different encoding than UTF-8, so for consistent behaviour across
> implementations, it is recommended to avoid non US-ASCII".  (yes, tongue
> is firmly in cheek.)

But that's not what we're saying.  We expect consistent handling of these 
strings across implementations.  Thus the "MUST accept" in 2.4.2.

> speaking of CRLF, I'd like a clarification of multi-line strings in
> section 2.4.2 (some of its text duplicates the above, I'm not sure
> that's good).  something like:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Haardt | 7 Aug 2006 15:01
Picon

OT: Are mailto URI argument names caseful?


Hello,

I am currently working on mailto notifications (so I am not entirely
off-topic;) and came accross a problem:

Are argument hnames in the query part of mailto URIs caseful?

RFC 2368 does not tell if the argument hnames resulting from splitting
the query part into pieces are caseful or not.  Neither does
draft-duerst-mailto-bis-02.  I did not get a response from asking the
authors.

In general, RFCs describing specific schemes must state if anything
is to be considered caseless.  Nothing is said -> caseful.

Hnames are caseless -> caseless.

Who will get a message resulting from the URI below and how will it
look like?

mailto:?to=user1 <at> example.com&TO=user2 <at> example.com

Using caseful names, the message would go to user1 <at> example.com, but
listing both recipients in the header, in case the client trusts the
message.  In case it does not and allows only safe headers, the message
would go to user1 <at> example.com and only listing that address in the header.

Any hints towards references I overlooked will be appreciated.
Please respond by private mail and I will summarise.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 7 Aug 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-body-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-04.txt
	Pages		: 12
	Date		: 2006-8-7
	
This document defines a new primitive for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-body-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |

Gmane