Re: [Uri-review] Request for review of "ab:" URI scheme

[Barry Leiba <[e-mail]>]

Hi, Bjoern, and thanks for the review.

> Could you explain why you have picked 'ab' as the scheme instead of
> something more verbose? This short it's hard to, say, put the name into
> a search engine and expect good to come up, even if you add "scheme" or
> some other keyword.

The string used was lightly debated in the working group.  We wanted
something short ("pab", for "personal address book" was also in the
running).  Things like "addrbook", "addressbook", and "adbk" were also
brought up.  Tony Hansen was the main proponent of something longer,
and Alexey was pushing for keeping it as short as possible.  I'll let
Alexey respond further; I'm happy to change it to "addrbook", and most
of the active participants have already said they'd be OK with that.

For what it's worth, we didn't discuss the issue of finding it in a
web search, so that's a new wrinkle.

> Why does this need an URI scheme to begin with? The draft notes that
> "An "ab" URI is designed to be used internally by applications for
> referencing address books." and if it's just used internally, then you
> could just use whatever you felt like, no need to use URIs.

The "internally" was phrasing of Alexey's, and might not have been the
best choice of words.  Alexey, why did you pick that word?

What's really the case here is that we need a standard and
interoperable way to refer to personal or organizational address
books, or sections/groupings/tabs within them.  We did consider using
an identifier that was strictly internal to Sieve, but decided an
address-book URI would be a better approach.  And see below.

> Do I understand correctly that a URI like `ab:friends` cannot be un-
> derstood without some additional context (you need a set of entities
> and a "friend" relation between them, for instance)?

As I said above, this is meant to expose an actual address book.
"ab:friends" has no particular semantics of what "friends" means,
other than that it's the name of an address book or a group
therewithin.  The implementation needs to know where to find the set
of addresses collectively called "friends", just as when I ask the
tools.ietf.org web server for http://tools.ietf.org/wg/sieve/, the
server needs to know where to find "wg".

> If I were to say, this shouldn't use a "ab" scheme, but, say, use an
> URN scheme, or some entirely different mechanism (say, make a list of
> keywords specifically for the "external lists" SIEVE extension), would
> that be some kind of problem, like, do underlying specifications re-
> quire this to be a URI scheme?

The sieve spec requires a URI, but there's nothing elsewhere that
depends upon this or defines it.  We could change this to say that it
can be a URI *or* something else (such as one of a set of well-known
registered strings).  That is, we think making a URI for this is the
right answer, but it would not be hard to change that.

> I think at the beginning of 4.3 you need to have some background infor-
> mation about the scheme that makes sense to people who have never ever
> heard of SIEVE, addressing the questions above (one or two short para-
> graphs should suffice).

We can do that.

> The draft needs to point out very clearly that implementations must,
> if they process non-internal URIs, properly implement URI processing,
> in particular %xx-escapes; right now the draft can easily be misread
> to suggest a literal string comparison against "ab:default" is all
> that is necessary for conformance.

Interesting.  A reference to RFC 3986 isn't enough for that?  (Of
course, I'd be happy to add such wording... but how much else do folks
need to be told about how to use URIs, and why isn't that in a central
place?)

Barry