ned.freed@innosoft.com
Tue, 06 Jun 2000 21:21:42 -0700 (PDT)
> immediate comments on the criticality flag:
> 1. I'd far rather see this as a content-disposition parameter, but
> this might be just a matter of taste.
I agree, and it isn't simply a matter of taste. There is already machinery
deployed to handle content-disposition; using it is a real savings for
implementors.
> 2. for DSNs, the interactions between notify/partial/ignore and the
> NOTIFY= SMTP parameter might need to be spelled out, preferably
> in a table. the current prose about this seems muddy.
Agreed as well.
> 3. "notify" and "partial" seem likely to invite confusion between
> SMTP NOTIFY and the "partial" message delivery status.
Yes, these aren't good choices. But IMO this goes even deeper -- this document
puts criticality solely on the axis of delivery notification generation. From
the Introduction:
In short, we need a method of indicating what sort of delivery
notification the sender requires on a per-body part basis.
I think this misses the point rather badly -- notifications aren't the
immediate issue, the issue is whether or not the message should even be
delivered, with notifications only being a consequence of that choice.
I could also see a criticality flag of this sort affecting where a message is
or isn't auto-forwarded by a smart delivery system.
I would therefore suggest putting this along the axis of criticality, not along
the axis of notifications. One you do this all sorts of choices suggest
themselves (e.g., essential/useful/nonessential).
> something like "critical", "semi-critical", "not-critical"
> might work better...but these are not quite right either.
> (what did X.400 use? I don't have it handy right now...)
FWIW, I think you're confusing X.400's tri-state attributes (priority
nonurgent, normal, urgent and sensitivity personal, private,
company-confidential) with X.400's criticality flag. The former are attributes
of a message; the latter is a boolean attribute of envelope extensions. That
is, in X.400 you can mark an envelope extension as to whether or not
understanding it is critical for message processing, and it is a yes/no choice.
There's no way in X.400 to mark anything in the header or body in a similar
fashion, and no associated useful terms in any case.
> 4. when to issue a DSN vs. when to deliver an MDN needs to be
> clarified - you send a DSN if the problem is detected at
> delivery time, you send an MDN if the problem is detected
> when the message is read.
Right.
> 5. there need to be DSN and MDN extensions to indicate which parts
> could not be converted/presented. this would presumably include
> new DSN status codes and new per-recipient, per-body-part, DSN
> fields to indicate the failure type and error message.
> (*please* don't invent new report types for these!)
I believe this is already being done in draft-ema-vpim-pndn-01.txt, although I
think this document needs work. It doesn't define a new report type (although
there is an apparenent remnant of when it did so in the table of contents
referring to message/partial-delivery-status).
FYI, issues I see in draft-ema-vpim-pndn-01.txt include:
(1) Use of separate sections in the delivery status area for different
parts as opposed to different recipients isn't backwards-compatible
and is likely to cause trouble with existing handlers of these things.
(The MIXER mapping to X.400 certainly breaks in this case, for example.)
I'd rather see everything pertaining to a single recipient in a single
section.
(2) The combination of a 5.x.y status with an action of "delivered" isn't
good either, although I'm not sure how to resolve it.
(3) Content-ids have the same syntax as message-ids, more or less. This
document presents them as simple strings.
(4) The dependency on content-ids is worrisome. Yes, any positional reference
may be thrown off by conversions and who knows what else, but some
indication may be better than nothing.
Ned
This archive was generated by hypermail 2.0b3 on Wed Jun 07 2000 - 08:05:05 IDT