Re: more 3028bis comments

[Kjetil Torgrim Homme <[e-mail]>]

On Tue, 2005-07-05 at 17:46 -0700, Ned Freed wrote:
> > > 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.
> 
> Actually I'm not. The current time, yes, but since the time of sieve evalaution
> isn't exactly specified in terms of its relationship to final delivery it
> doesn't make sense to have this as part of a general date extension. It would
> at best be another, separate extension.

true, it would be best to make it a separate extension so that "date"
deployment is not hampered.  the "deliverydate" extension could probably
be specified by adding a couple of paragraphs to the "date" document,
though.  whether that feels natural we'll see later.

> > > The 'variables' extension has to specify greedy/non-greedy ":matches" ;
> > > this really ought to be in 3028 so that extensions can consistently
> > > follow whatever rule there is; although, again, it might fail the
> > > "non-substantive" test.
> 
> > I don't think this behaviour description is relevant for the main spec.
> > it can not be observed without the variables extension.
> 
> Yes, exactly so. This could easily come back to bite us when we need to move to
> draft.

sorry, I'm dense.  are you agreeing with Mark or with me?

I don't worry about this issue since I trust we will be able to avoid
publishing extensions with incompatible behaviours in the future, even
when the extensions don't depend on each other.  there will always pop
up be cases such as this, and we can't get all such behaviours described
in the base spec.
-- 
Kjetil T.