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

[Alexey Melnikov <[e-mail]>]

Barry Leiba wrote:

>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.
>
I prefer a shorter version, but this is not a big deal for me. 
"addrbook" is certainly fine.

>For what it's worth, we didn't discuss the issue of finding it in a
>web search, so that's a new wrinkle.
>  
>
Right. So maybe "ab" is not such a good name after all.

>>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?
>
The use case I had in mind is use by something like Thunderbird to 
reference an address book entry. Many applications use URIs internally, 
or to communicate between different applications or between the OS and 
an application.

But having said that I don't think I can anticipate all use cases for 
this URI scheme, so maybe dropping the word "internally" is the best thing.

>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.
>
Right.

>>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,
>
Agreed.

>but it would not be hard to change that.
>  
>
That would introduce extra complexity and I am not a big fan of 
unnecessary complexity.

Best Regards,
Alexey