ietf-mta-filters
[Top] [All Lists]

Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications

2009-07-30 11:16:18


Proposal: Separate Section For Discussion of TAG
=================================================
Changes
-------
Split first paragraph into sections.
Rationale
---------
Clarity

Proposal: Clarify Expected Error Handling Behaviour
===================================================
Changes
-------
Specify that unsupported URI schemas are compile time
errors and that resolution failures are runtime errors.

While I agree it's a good idea to report errors at as early a phase as
possible, unless we're willing to specify that variable substitutions cannot be 
used in list names, this can at most be a SHOULD, not a MUST.

Rationale
---------
Practical implementations will not be able to support
all feasible URI schemes, protocols, discovery mechanisms
and resource semantics.

Any URI schema which is not supported by the engine
will never be resolved. In this case, it is clearer and
cleaner to fail at compile time. Note that this case
also includes malformed URIs.

Resources may be dynamic. A resource whose semantics
could not be understood at compile time may have been
replaced by one that could be at runtime. Resource
resolution may be dynamic: a resource which could not
be resolved at compile time may be resolvable at
runtime. Services may be dynamic. A service with
suitable semantics may become available at runtime
which was not at compile time. Conversely,
resources, resource resolution and service discovery
may fail at runtime after it succeeded at compile
time.

So, failures to resolve, locate or parse a resource
referred to by the script should only be raised at
runtime.

Agreed, however, it isn't clear to me that throwing an error is the right
thing to do when a given list resource is unavailable. Handling the
unavailability of a given resource is well within the purview of a properly
constructed portable script, I should think.

Proposal: Require Implementations To Support [TAG-URI]
======================================================
Changes
-------
Require that all implementations support tag, plus any other
URI schemes of their choice.
Rationale
---------
Insisting that implementations support at least one protocol
sets a minimum level for script portability. Picking one
particular web protocol such as LDAP, HTTP or FTP would impose
a unnecessary burden on implementations and
unnecessarily involve the specification in the semantics of
engine-list server interactions.

A credible alternative choice would be relative URIs.

It's unclear what "support" means in this context. In our implementtation list
URIs are parsed and then passed to what amounts to a callout. We can of course
make it so tag: is always a legal URL type when that check is done, but we
cannot force tag: to work.

--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   Implementations MUST raise a compile time error when a list name
   cannot be parsed into a URI scheme supported by the implementation.

See above. This needs to be a SHOULD.

   Resolution of the resource MAY involve resource location and service
   discovery. Resources MAY change dynamically. Resolution of the
   resource MUST be perform at script execution time. When the resource
   cannot be located or the resource type is found to be unsupported
   then the implementation MUST raise a runtime error.

If we're going to throw an error like this in a  test I think we need a way to
test and see if the resource is available.

   Implementations MAY attempt to resolve the URI at compile time but
   MUST NOT raise a compile time error on failure.

2.4.1 The Tag Scheme
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.

   Resolution of such identifiers is going to be implementation specific
   and it can help in hiding the complexity of an implementation from
   end users.  For example, an implementation can provide a web interface
   for managing lists of users stored in LDAP.  Requiring users to know
   generic LDAP URL syntax might not be very practical, due to its
   complexity.  An implementation can instead use a fixed tag URI prefix
   such as "tag:example.com,<date>:" (where <date> can be, for example,
   a date generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

   Implementations MUST support the [TAG-URI] URI scheme.

I think some elaboration on what "support" means would be good here.

2.4.2 Other URI Schemes

   Implementations MAY support other URI schemes.


                                Ned