Re: more 3028bis comments

["Mark E. Mallett" <[e-mail]>]

On Tue, Jul 05, 2005 at 05:46:18PM -0700, Ned Freed wrote:
> > On Tue, 2005-07-05 at 16:52 -0400, Mark E. Mallett wrote:
> > > 2.2.     Whitespace
> > >
> > >    > Whitespace is used to separate tokens.  Whitespace is made up of
> > >    > tabs, newlines (CRLF, never just CR or LF), and the space character.
> > >    > The amount of whitespace used is not significant.
> > >
> > > This is specifically about whitespace in the Sieve language.  So... how
> > > many implementations violate this?  i.e., does everyone generate an
> > > error if a script's whitespace contains a naked CR or LF ?
> 
> > does it matter?  this text is unchanged from RFC 3028, so it will not
> > affect conformance.
> 
> I see no "MUST generate an error" clause here, so as far as I'm concerned the
> handling of bare CR and bare LF means you have a nonconformant script, but how
> implementations handle this particular form of nonconformance is undefined.
> 
> Attempting to nail this down to a "MUST generate an error" would be a huge
> mistake IMO, given the use of bare LF and bare CR as the default line
> terminators on many systems. And I really don't want to repeat the whole
> "canonical format versus local storage format" discussion again, thank you very
> much. So let's let this particular sleeping dog lie, OK?

Oh- I had forgotten that you asked that, when I wrote my other response,
sorry.  I have a hard time letting go that the spec mandates something
that is probably impossible to follow, and likely derives from something
that's not relevant (i.e., wire format).  But other than making this
side comment, I will indeed let it go :-)



> > > 2.10.6.  Errors
> > >
> > >    > When an error happens, implementations MUST notify the user that an
> > >    > error occurred, which actions (if any) were taken, and do an implicit
> > >    > keep.
> > >
> > > Probably extremely nit-picky, but I've always wondered when I read
> > > this "what user, and how do we notify them?"  Some users have no
> > > access to anything other than their mailboxes.  I suspect that many
> > > implementations will do some system-wide logging, which notifies the
> > > admin, but not the user.
> 
> > good question.  delivering an error report to INBOX in addition to the
> > message is one way of solving this, but does anyone do this?

I do something like that, in a way that's not very clean and I'm not
very proud of, which is one reason I asked the question..  I file any
error message text along with the same message that caused it.  (We also
have a personal logfile facility, but that's not guaranteed to be accessible
by the end user, nor is the end user likely to check it very often.)


> We do. Our implementation has the concept of a "responsible address" that's
> attached to each sieve script. When an error occurs this address is notified of
> the problem. For user sieves this is the user's own address, system sieves have
> the main system postmaster as the responsible address, and so on.

That sounds like an interesting idea and is probably worth pursuing as
an alternative.  Thanks..


> > > The spec provides no way to access the "From_" line (which is the
> > > "From<sp>" line with no colon that is added by some mail software.
> > > While it's not part of RFC2822, and admittedly a minor concern at
> > > best, that 'header' is often there, but inaccessible.  I have no
> > > solution, other than perhaps making "From_" a special header name.
> 
> > we have envelope "from" for the e-mail address.  we don't have anything
> > for the delivery date, but I suspect Ned is considering that for his
> > "date" extension.

I was talking about accessing the header field in same ways that others
can be accessed, not other ways of getting at the specific parts of that
field that we might predict people might want.  I've seen occasions
where script writers either want to suppress the line if supplied, or
add one if not, e.g.:

    if exists "From_" { deleteheader "From_" };

as a very simple case.  Knowing that you can't access that (admittedly
fake) is a thing by itself, without having to say all the things that
you might want to do with it.  Anyway it was simply on my collected list
of known issues that I was looking at while making the posting.

-mm-