Cyrus Daboo wrote:
Hi Alexey,
--On November 30, 2010 7:38:03 PM +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
This specification requests the IANA to register the
"pab" URI scheme as specified in this document and summarized in
the following template, per [RFC4395]:
URI scheme name: pab
So I am not convinced we should have this URI scheme (though that is
not a strong objection).
If we do stick with it, then:
1) Since you have broadened the scope to "applications" in general,
why does this have to remain a "personal" reference? What about shared
or global address books available to the application. i.e. shouldn't
this be "ab" rather than "pab"?
I am not wedded to the name, as long as it is short.
2) I wonder if we want to be more generic - not just address books
(e.g. I could easily imagine a SIEVE system looking at my calendar to
determine possible vacation times automatically - i.e. it would be
nice to just add an all-day event to a special "vacation" calendar and
have that automatically turn on SIEVE vacation for that day). So if we
stick with a URI, why not target it specifically at sieve, but allow
for different types, e.g. have a 'sieveid' scheme that can be used to
represent any external "system" identifier needed in a SIEVE script.
The syntax could include a type specifier as the first item, e.g.:
sieveid:addressbook:default
sieveid:calendar:vacation
I think people complained about length (the same comment was made about
URNs). I think these should be short, otherwise we might as well keep
using tag:.
To be frank I am not convinced about usability of generic Sieve URIs. I
would rather have 2 different URI schemes that are easy to explain, then
a one combined.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve