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

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Apr 2011 13:36:58 -0400

In the Sieve working group, draft-ietf-sieve-external-lists defines an
address-book URI scheme, "ab:".  See the draft, here:
http://tools.ietf.org/html/draft-ietf-sieve-external-lists

We would like to get uri-review comments on the proposed scheme.
There's a reference to the scheme in section 2.5, it's used in the
examples in section 2.8.1 and at the end of the Security
Considerations (section 3), and it's defined and registered in section
4.3.

Thanks in advance for reviews and comments.

Barry

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Apr 2011 20:54:50 +0200

>http://tools.ietf.org/html/draft-ietf-sieve-external-lists

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.

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.

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)?

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?

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

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.

(In the registration template, I don't think the "Encoding consider-
ations" are quite right, but this was an open issue in the IRI WG when
stopped keeping track, so I am not sure it's wrong or what to replace
it with).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Apr 2011 15:54:16 -0400

Hi, Bjoern, and thanks for the review.

> a search engine and expect good to come up, even if you add "scheme" or

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.

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

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

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

> heard of SIEVE, addressing the questions above (one or two short para-

We can do that.

> 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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 21 Apr 2011 22:14:51 +0200

* Barry Leiba wrote:
>[...]

(I, or others, will look at this when Alexey had a chance to respond.)

>need to be told about how to use URIs, and why isn't that in a central

The problem is that you are enumerating values like "ab:default" and
"ab:friends". Since it does not really make sense to write, instead,
"ab:%64efault", or, for that matter, "AB:default", I do think it is
important to re-inforce that this is URI processing and not keyword
matching. It would be well-defined without the reminder, but there's
little reason to expect implementers to get this right on their own.

(If escaping rules were second nature to everybody, there would be,
say, no SQL injection attacks, no XSS attacks, and so on.)

(I would probably make an example with something like "AB:%64efAulT"
and put up a note saying the example demonstrates that the scheme
name is case-insensitive and that escapes must be processed properly;
I am not sure if the draft defines if "default" is case-sensitive.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Apr 2011 16:16:40 -0400

> little reason to expect implementers to get this right on their own.

ACK.

> I am not sure if the draft defines if "default" is case-sensitive.)

ACK.  Will do.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Apr 2011 21:35:04 +0100

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

>web search, so that's a new wrinkle.
Right. So maybe "ab" is not such a good name after all.

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

>address-book URI would be a better approach.  And see below.
Right.

>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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 22 Apr 2011 16:38:40 +0300

> http://tools.ietf.org/html/draft-ietf-sieve-external-lists
Hello,

I have some other minor comments to this URI scheme registration.  First 
of all, +1 to almost all comments from Björn Höhrmann.  I fully agree 
with all the issues he raised, except the one - see below.

Now, some remarks to Section 4.3 of this document.

> 4.3. Registration of "ab" URI Scheme
>
>
>     The following requests IANA to register a new URI scheme according to
>     the IANA registration template specified in [RFC4395]:
I see RFC 4395 is normative reference here.  I do not think reading this 
document should be compulsory for understanding your document.  Maybe 
Informative reference is more appropriate here.
>     URI scheme name:  ab
>
>     Status:  Permanent
>
>     URI scheme syntax:
>         paburi = "ab:" addrbook [ "?" extensions ]
>         addrbook = segment
>              ;<segment>  defined in [RFC3986]
>         extensions = query
>              ;<query>  defined in [RFC3986]
I understand this is defined with ABNF.  Your document in Section 1.1 
mentions this, but I think mentioning this issue once more in the 
template wouldn't be harmful, as I propose below.

You can also add something like "/The "ab" URI takes the form of 
<paburi> rule below, defined using ABNF [RFC5234]./"  I also do not 
understand why the scheme name is "ab" whereas the rule is "*pab*uri".  
If you decide to change the scheme name per comments from Björn, this 
rule should also be corrected.
>     URI scheme semantics:  "ab" URIs are used for designating references
>         to address books.  An address book is an internal concept used by
>         different applications (such as Sieve interpreters) for
>         describing a list of named entries, and may be translated into
>         other types of address books, such as LDAP Groups.  Address books
>         may be private or shared; they may be personal, organizational,
>         or perhaps even "crowdsourced".
This section should also have some words about the role of <addrbook> 
and <extensions> parts in the URI.
>     Encoding considerations:  Percent-encoding is allowed in "segment"
>         and "query" components.  Internationalization is handled by IRI
>         processing.
I see this is already commented by Björn.
>     Intended usage:  An "ab" URI is designed to be used internally by
>         applications for referencing address books.  Each URI is intended
>         to represent a grouping of addresses that can be logically
>         thought of as one "book".  Any given address can belong to more
>         than one book -- that is, can be referred to by more than one
>         URI.
> [ . . . ]
>
>     Applications and/or protocols that use this URI scheme name:
>         Currently only the Sieve External List extension is using this
>         URI scheme.  Email clients that use URIs internally might find
>         this URI scheme to be useful as well.
>
>     Interoperability considerations:  Applications are only REQUIRED to
>         support "ab:default".
I cannot find any distinctive description of this reserved URI, 
information about what it is used for.  Having at least sentence dealing 
with this issue would be OK, I think.
>     Security considerations:  Applications SHOULD ensure appropriate
>         restrictions are in place to protect sensitive information that
>         might be revealed by "ab" URIs from access or modification by
>         untrusted sources.
I do not see anything regarding the URI scheme in your section 3.  While 
it concerns the proposed extension, some words specifically about the 
URI scheme won't be redundant, IMO.
>     Relevant publications:  this RFC
>
>     Contact:  Sieve mailing list<[email-masked]>
Shouldn't this be "Sieve WG <[email-masked]>".  Maybe the same is below 
- it should be just IESG, shouldn't it?

>     Author/Change controller:  IETF/IESG
Now,

> heard of SIEVE, addressing the questions above (one or two short para-
I do not think such information should go at the beginning of Section 
4.3.  This section is aimed just to provide IANA guidelines for 
registration.  Having it is a good idea, but somewhere else, eg. in 
Section 2.5.

Thanks for considering my comments in advance.

Mykyta Yevstifeyev

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Apr 2011 10:16:32 -0400

> Informative reference is more appropriate here.

Clearly not; see below.

> mentions this, but I think mentioning this issue once more in the template
> wouldn't be harmful, as I propose below.

RFC 4935, along with RFC 3986 (which 4935 references) makes it clear
that URI schemes are defined with ABNF.  I see no reason to add
anything further here.

> You can also add something like "The "ab" URI takes the form of <paburi>
> rule below, defined using ABNF [RFC5234]."  I also do not understand why the
> scheme name is "ab" whereas the rule is "paburi".  If you decide to change
> the scheme name per comments from Björn, this rule should also be corrected.

The names of the ABNF elements aren't related to the text strings that
they produce.  There's no reason for any change here.

>    URI scheme semantics:  "ab" URIs are used for designating references
...
> This section should also have some words about the role of <addrbook> and
> <extensions> parts in the URI.

You're right; I thought that was already in there, but it's not.  I'll
add something.

> I cannot find any distinctive description of this reserved URI, information
> about what it is used for.  Having at least sentence dealing with this issue
> would be OK, I think.

It's in the second paragraph under "Intended usage:".

> I do not see anything regarding the URI scheme in your section 3.  While it
> concerns the proposed extension, some words specifically about the URI
> scheme won't be redundant, IMO.

Yes, that's reasonable.  I'll add.

>    Contact:  Sieve mailing list <[email-masked]>
>
> Shouldn't this be "Sieve WG <[email-masked]>".  Maybe the same is below - it
> should be just IESG, shouldn't it?

Huh?  I don't understand what you're getting at.  The contact
information is correct, and isn't related to who has change control
(the IESG).

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Apr 2011 11:35:46 -0400

>>http://tools.ietf.org/html/draft-ietf-sieve-external-lists

In response to comments by Bjoern and Mykyta, I have changed the
scheme to "addrbook".  Apart from that change, I've made the following
other changes to the draft.  If these satisfy the concerns, I will get
approval from the working group, and we'll proceed with sending the
document to the IESG.

Barry

===============================================
In Introduction, section 1:
OLD
<    The "ab" URI scheme (in particular, the URI "ab:default"), defined in
<    Section 4.3 MUST be supported.  The mandatory-to-implement URI "ab:
<    default" gives access to the user's default address book (usually the
<    user's personal address book).
NEW
>    The "addrbook" URI scheme (in particular, the reserved URI "addrbook:
>    default"), defined in Section 4.3 MUST be supported.  The mandatory-
>    to-implement URI "addrbook:default" gives access to the user's
>    default address book (usually the user's personal address book).
>    Note that these are URIs, subject to normal URI encoding rules,
>    including percent-encoding.  The reserved name "default" MUST be
>    considered case-insensitive after decoding.  That means that the
>    following URIs are all equivalent:
>
>       addrbook:default
>
>       ADDRBOOK:DEFAULT
>
>       aDdRbOOk:DeFauLt
>
>       AddrBook:%44%65%66ault
>
>     Address book names other than "default" MAY be case-sensitive,
>     depending upon the implementation, so their case (after URI
>     decoding) MUST be maintained.

At the end of Security Considerations, section 3:
NEW
>    Applications SHOULD ensure appropriate restrictions are in place to
>    protect sensitive information that might be revealed by "addrbook"
>    URIs from access or modification by untrusted sources.

In "URI scheme semantics:" in section 4.3:
NEW
>        The address book name (the "addrbook" element in the ABNF above)
>        refers to a specifically named address book, as defined by the
>        implementation.  A user might, for example, have access to a
>        number of different address books, such as a personal one, a
>        family one, a company one, and one for the town where the user
>        lives.
>
>        The extension information (the "extensions" element in the ABNF
>        above) is available for use in future extensions.  It might allow
>        for things such as dynamic subsets of an address book (for
>        example, "addrbook:personal?name.contains=fred").  There are no
>        extensions defined at this time.

In "Encoding considerations:" in section 4.3:
NEW
>        In particular, note that implementations MUST properly implement
>        URI processing, including percent-encoding.  Any comparisons,
>        lookups, and so forth are done after all decoding of the URI.

In "Intended usage:" in section 4.3:
Remove the word "internally" in the first sentence, and add
"case-insensitive" in the second paragraph.

In "Interoperability considerations:" in section 4.3:
OLD
<        Applications are only REQUIRED to
<        support "ab:default".
NEW
>        Applications are only REQUIRED to
>        support "addrbook:default", where all cases and encodings of
>        "default" are considered equivalent.  Address book names other
>        than "default" MAY be case-sensitive, depending upon the
>        implementation, so their case (after URI decoding) MUST be
>        maintained.

===============================================

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 22 Apr 2011 19:29:58 +0300

> approval from the working group, and we'll proceed with sending the
I think these proposed changes almost fully cover those concerns I 
pointed to.  However see some remarks in-line.  (I also think Bjoern's 
comments are also considered here, but let's wait for his personal 
response).
>>     including percent-encoding.
Shouldn't the reference to RFC 3986 go here?
>>         extensions defined at this time.
I think some words about how these extensions are specified would be 
relevant.
All other changes, as mentioned below, are OK.  I'd also like to ask 
about some of my comments not included above:

> >  You can also add something like "The "ab" URI takes the form of<paburi>
Anyway, <paburi> rule will make the reader a bit confused.  The 
<addrbook-uri> or <addrbookuri> would obviously be more appropriate here.

> >  Informative reference is more appropriate here.
I did not find anything related to this issue "below".

The "Contact", according to RFC 4395 is:

>   Person (including contact information) to contact for further
>        information.
(Organizations are also permitted).

The mailing list cannot be 'Contact'.

Mykyta Yevstifeyev

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Apr 2011 19:13:37 +0100

Hi Mykyta,

 [...]

> The mailing list cannot be 'Contact'.

You might be correct from a pedantic standpoint, but mailing lists were 
used as Contact quite often recently. They are more reliable than a 
single person.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Apr 2011 19:18:56 +0100

Hi Mykyta,

 [...]

> Shouldn't this be "Sieve WG <[email-masked]>".  Maybe the same is 
> below - it should be just IESG, shouldn't it?

The Sieve WG is likely to close at some point, however the mailing list 
is likely to remain. So calling this "Sieve mailing list" is more 
appropriate.

I don't think having IESG as the Contact is a good idea either. The 
Contact field is an email address to use for asking about the 
registration, it would be much better to have a more relevant (specific) 
email address.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Apr 2011 14:41:25 -0400

...
> Shouldn't the reference to RFC 3986 go here?

Actually, that was my error; that's not in section 1, but in section
2.5.  And the reference is already earlier in section 2.5, so we're
fine.

> I think some words about how these extensions are specified would be

I don't.  It's well known what "future extensions" means.  I don't see
that we need to tell people about writing extension RFCs.

> <addrbook-uri> or <addrbookuri> would obviously be more appropriate here.

I disagree.  Again, ABNF construct names often don't correlate to the
strings that they produce.  This is fine as it is.

> I did not find anything related to this issue "below".

It was right there: your concern that someone might not understand
that we used ABNF.  I suppose one could say that the 3986 reference is
sufficient for that, but I'm happier leaving 4395 as normative.

Barry

---

From: Graham Klyne <[email-masked]>
Date: Fri, 22 Apr 2011 20:27:01 +0100

(For the avoidance of doubt, these comments are made with my URI scheme reviewer 
hat OFF.)

I am reminded of recent discussions about the jms: scheme, and how appropriate 
it is to mint a new URI scheme for accessing information for which there is no 
specific access protocol.  The fundamental problem is "The use and deployment of 
new URI schemes in the Internet infrastructure is costly;" 
(http://tools.ietf.org/html/rfc439) and "New URI schemes SHOULD have clear 
utility to the broad Internet community, beyond that available with already 
registered URI schemes." (ibid).

As I recall, the jms: scheme was allowed because there was a significant body of 
usage in code, if not on the wire.  Similarly, the recently discussed about: 
scheme was looked upon favourably because it was essentially codifying what 
browsers have been doing since the very early days.

In this case, I see no evidence of prior use to be accommodated, nor do I see 
any *technical* reason why an existing scheme cannot be used.  As I read your 
document, the only *required* value is ab:default - everything else is 
implementation dependent.  My suggestion would be to use instead 
"http://ietf.org/sieve/addrbook#default" (and, as a bonus, create a web page at 
that address explaining what it means).  The other values can be arbitrary URIs 
chosen by implementers.  if there is a future need for additional interoperable 
values, the above pattern is easily extended.  (My use of "#default" rather than 
"/default" is to sidestep an obscure issue of web architecture, but either could 
be used.)

Some folks are uncomfortable with http: URIs that represent not just web pages, 
but using http: URIs in this way is now a widely established practice in web 
data cicrles.  If you really don't like the http: approach, other possibilities 
might be a urn namespace - there's already a URN namespace for protocol 
parameters (http://tools.ietf.org/html/rfc3553), so one might end up with 
something like "urn:ietf:params:sieve:default".

In summary, in this case, I don't think the case has been made that a new URI 
scheme is justified.

#g
--

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 23 Apr 2011 08:32:20 +0300

Hello Barry, all,

> 2.5.  And the reference is already earlier in section 2.5, so we're
This is OK.
> that we need to tell people about writing extension RFCs.
OK, -as is- is fine.
>> Anyway,<paburi>  rule will make the reader a bit confused.  The
>> <addrbook-uri>  or<addrbookuri>  would obviously be more appropriate here.
So how will the reader know that the 'addrbook' URI is defined in 
<paburi> rule?  Let's employ common sense.

Having no introducing sentence to this template field is not good as 
well, I think.  Therefore I do insist on putting the following contents 
of URI Scheme Syntax:

>
> The "addrbook" URI takes th form of <addrbook-uri> rule below, defined 
> using ABNF [RFC5234]:
>
> addrbook-uri = "addrbook:" addrbook [ "?" extensions]
> addrbook       = segment
> extensions     = query
>
> where <segment> and <query> are defined in Appendix A of RFC 3986 
> [RFC3986]

> sufficient for that, but I'm happier leaving 4395 as normative.
4395 has even no mention of "ABNF" or its full name.  Moreover, having 
4395 document as an *Informative* reference is something like a 
tradition in URI-scheme-specifying docs :-).

Also agree with all responses from Alexey.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Sat, 23 Apr 2011 08:24:04 -0400

>> where <segment> and <query> are defined in Appendix A of RFC 3986

OK, that seems harmless.  I'll change that.

> 4395 has even no mention of "ABNF" or its full name.  Moreover, having 4395
> document as an *Informative* reference is something like a tradition in
> URI-scheme-specifying docs :-).

I'm happy to change it to informative if Alexey agrees.

Of course, there's also Graham's comment, which could make all this
moot anyway.  We have to think about that a bit more.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Apr 2011 22:28:19 +0100

>OK, that seems harmless.  I'll change that.
+1.

>I'm happy to change it to informative if Alexey agrees.
I don't have a strong opinion on Informative versa Normative for RFC 
4395. This is usually a border case.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Apr 2011 21:17:50 +0100

Hi Graham,
Let me try to defend my proposal and we can see if I can change your mind.

Graham Klyne wrote:

> (For the avoidance of doubt, these comments are made with my URI 
> scheme reviewer hat OFF.)
>
> I am reminded of recent discussions about the jms: scheme, and how 
> appropriate it is to mint a new URI scheme for accessing information 
> for which there is no specific access protocol.

IMHO, the issue with jms: URIs was different: there was no 
*interoperable* protocol behind it.

I am thinking of the ab: URI scheme as similar to mailto:. For mailto: 
there is no protocol behind it, at least there is no requirement for 
using SMTP transaction for operating on mailto URIs. A typical operation 
on a mailto URI is "open a mail composition window". Similarly, for an 
ab: URI it is going to be "open the addressbook viewer window".

In the last months I've seen a couple of Windows application registering 
URIs for similar kind of API use. One application is for gift vouchers 
for a game download application, another one for a music download 
application. I think these are pretty similar to mailto: and ab:. If 
these are not supposed to be legal uses of URIs, then I think IETF 
community needs to build some consensus against that.

> The fundamental problem is "The use and deployment of new URI schemes 
> in the Internet infrastructure is costly;" 
> (http://tools.ietf.org/html/rfc439) and "New URI schemes SHOULD have 
> clear utility to the broad Internet community, beyond that available 
> with already registered URI schemes." (ibid).
>
> As I recall, the jms: scheme was allowed because there was a 
> significant body of usage in code, if not on the wire.  Similarly, the 
> recently discussed about: scheme was looked upon favourably because it 
> was essentially codifying what browsers have been doing since the very 
> early days.
>
> In this case, I see no evidence of prior use to be accommodated,

That is true.

> nor do I see any *technical* reason why an existing scheme cannot be used.

I think I've tried to make my case above. But also see below for some 
additional reasons, some of which are non technical.

> As I read your document, the only *required* value is ab:default - 
> everything else is implementation dependent.  My suggestion would be 
> to use instead "http://ietf.org/sieve/addrbook#default" (and, as a 
> bonus, create a web page at that address explaining what it means).  
> The other values can be arbitrary URIs chosen by implementers.  if 
> there is a future need for additional interoperable values, the above 
> pattern is easily extended.  (My use of "#default" rather than 
> "/default" is to sidestep an obscure issue of web architecture, but 
> either could be used.)
>
> Some folks are uncomfortable with http: URIs that represent not just 
> web pages, but using http: URIs in this way is now a widely 
> established practice in web data cicrles.  If you really don't like 
> the http: approach, other possibilities might be a urn namespace - 
> there's already a URN namespace for protocol parameters 
> (http://tools.ietf.org/html/rfc3553), so one might end up with 

The Sieve WG looked at tag: URIs and URNs. (We didn't look at using 
http:, but I do have a bit of distaste for that proposal).
The tag: URI was almost Ok, but then the use of a fake date which has no 
semantic meaning made us think that maybe use of a new URI scheme would 
be better. So here we are.

The main issue for Sieve uses cases is that Sieve scripts can be typed 
by users manually (using a normal text editor), not all Sieve scripts 
are generated by special UIs. For manual editing URIs should be 
short(ish) - in order to avoid typing long strings and risking 
introducing errors. This was the main reason for not choosing URNs.

> In summary, in this case, I don't think the case has been made that a 
> new URI scheme is justified.
>
> #g
> -- 
>
> Barry Leiba wrote:
>
Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov

---

From: Graham Klyne <[email-masked]>
Date: Tue, 26 Apr 2011 13:25:26 +0100

> Let me try to defend my proposal and we can see if I can change your mind.

Alexey,

You provide some useful additional context, but I'm not yet fully convinced. 
But by all means let's kick this one about and see where it ends up.

> ab: URI it is going to be "open the addressbook viewer window".

I note that mailto: may not be bound to SMTP, but it is pretty closely bound 
with RFC822 (et seq).

> community needs to build some consensus against that.

Ah, there's a whole discussion to have.  Maybe something to bring up in the 
IETF/W3C liaison group?  Is it appropriate to mint URI schemes to access a local 
application?  mailto: is a precedent here, but one that was established before 
many of the concerns about URI scheme profligation became more widely voiced.

At heart, it comes down to "what are URIs for?".  Off the top of my head, I suggest:
- identifying resources (all URIs do this, and addrbook: passes on this)
- in many cases, providing information that can be used interoperably to 
interact with the identified resource; often this means identifying a protocol 
and associated parameters.  mailto: seems to sit right out at the edge here, and 
is to some extent justified by its ubiquity and widespread utility.  For this, 
maybe we have to allow that not all protocols are wire protocols?

> additional reasons, some of which are non technical.

I didn't really see any technical case above.  (Though I could imagine a more 
richly defined addrbook: URI having utility on a scale to compare with mailto: - 
from my perspective, SIEVE looks like a fairly narrow use-case, though maybe I 
misunderstand the context of expected SIEVE usage.)

> introducing errors. This was the main reason for not choosing URNs.

FWIW, This is the argument I find hardest to dismiss.  As in so many of these 
discussions around URIs, the core issues are often social, not technical.  I can 
imagine alternative approaches, but without better understanding the context of 
intended use it would be rash of me to push alternative designs.

So here's a question to start with:  in the Sieve context where you see 
addrbook: URIs being used, do you anticipate that other kinds of URI might also 
be used?

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Apr 2011 08:59:37 -0400

Hi, Graham.

> I didn't really see any technical case above.  (Though I could imagine a
> more richly defined addrbook: URI having utility on a scale to compare with
> mailto: - from my perspective, SIEVE looks like a fairly narrow use-case,
> though maybe I misunderstand the context of expected SIEVE usage.)

The "more richly" is the reason for the extension stuff after the "?".
 We anticipate other uses of it, which will add refinement and
details, but we don't have those to hand now, so we're leaving them to
be defined later.  Browser-based applications that access online and
offline address books could likely use these, for example.  Things
like "add to address book" links might be very useful.

>> The main issue for Sieve uses cases is that Sieve scripts can be typed by
>> users manually (using a normal text editor), not all Sieve scripts are
>> generated by special UIs. For manual editing URIs should be short(ish) - in
>> order to avoid typing long strings and risking introducing errors. This was
>> the main reason for not choosing URNs.
>
> FWIW, This is the argument I find hardest to dismiss.  As in so many of
> these discussions around URIs, the core issues are often social, not
> technical.  I can imagine alternative approaches, but without better
> understanding the context of intended use it would be rash of me to push
> alternative designs.
>
> addrbook: URIs being used, do you anticipate that other kinds of URI might
> also be used?

We do.  The document
   http://tools.ietf.org/html/draft-ietf-sieve-external-lists-07
suggests LDAP, ACAP, and CalDAV URIs as three likely ones.  The point
here is that any URI that can be considered to resolve to some sort of
list is useful here.

We had long discussions about what to use for the name that points to
the list.  We included opaque strings (no interoperability at all), a
registry of well-known strings, and other such.  We settled on URIs
only after a lot of discussion... so this wasn't just a casual "OK,
let's use URIs; next issue?" thing.

Barry

---

From: Graham Klyne <[email-masked]>
Date: Tue, 26 Apr 2011 15:12:24 +0100

Barry,

OK, I think I'm starting to see the _potential_ wider benefits here.  Your 
thoughts about "more richly" parallel those I was having, and I see that 
interchangeability with LDAP, CalDAV, etc. has real potential value.

I find I'm left with a nagging worry, though.  While I agree it's not 
appropriate to try and define addrbook: URIs more richly at this stage, 
especially as part of Sieve, I fear that if they end up growing by accretion 
rather than with some coherent rationale they could end up failing to realize 
their potential utility.

For example, and from the top of my head, I think it could be helpful to be clear:
(1) what kind of resource is identified by an addrbook: URI (a set of 
address-book entries? OR a specific address-book entry with indicated content?)
(2) what kind of representations one might get back on de-referencing an 
addrbook: URI (e.g. if one is placed as a link on a web page, what might one get 
by clicking on it?).  (I don't mean to specify a particular format here.)
(3) what other kinds of operation (other than dereferencing) might be 
appropriate for these URIs?  This is an area where I think the mailto: URI might 
not be such a great model to follow, as it some ways it sits uneasily with other 
expectations of Web architecture.  (I've tried to avoid appealing to Web notions 
up to now, but I don't think that can be completely avoided, as URIs *are* 
probably the most fundamental technical underpinning of Web architecture, and I 
do think we should try not to create additional problems there.)

In particular, concerning point (3), I think that an "add to address book" 
functionality encoded within a URI would be a Bad Thing.  But allowing that 
operations like Add, Update and Delete might usefully be applied to such URIs

Another point about which I worry is the potential mismatch between being able 
to use such URIs as part of the process of, say, adding an entry to an address 
book, and in a context that allows "any URI that can be considered to resolve to 
some sort of list".  (But this maybe a probhlem for the Sieve protocol, not the 
proposed URI scheme.)

In summary, I find myself in the slightly uncomfortable position of liking the 
potential for what an addrbook: URI scheme might offer, but fearing that the 
immediate requirement coming from the Sieve protocol has too small a "contact 
area" with the URI to meaningfully shape the URI technical specification to be 
able to achieve those goals in later developments.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Apr 2011 11:17:32 -0400

> rather than with some coherent rationale they could end up failing to
> realize their potential utility.

Understood.  So our goal, here, is to make sure that this definition
has the right bits in it to steer things in the right direction, and
the right extensibility to allow it to go there when it needs to.

> address-book entries? OR a specific address-book entry with indicated

I tried to get to that with the update that I posted in an earlier
message, repeated here:

>        extensions defined at this time.

The idea here is that an unadorned addrbook URI refers to an "address
book" -- that is, a set of address book entries.  Extension elements
can further specify that, reducing the set, or specifying individual
entries.  Consider (and don't worry about syntax here):

1. addrbook:personal
2. addrbook:personal?name.contains=fred
3. addrbook:personal?email=[email-masked]
4. addrbook:personal?entry=314159265

The first clearly provides a "whole book", a set of entries.  The
second is likely to give a set of entries, but the set could have
cardinality 1.  The third is likely to give a set of cardinality 1,
but it's possible for it to be > 1.  The fourth is specifying a single
entry by its unique ID.

> addrbook: URI (e.g. if one is placed as a link on a web page, what might one
> get by clicking on it?).  (I don't mean to specify a particular format
> here.)

I figure the browser interface has one right-click to get a set of
options, which might include opening the book (or set of entries, or
individual entry) in an address-book-browser widget or app, merging
the set of entries into another address book, exporting the book/set
(saving it locally), and so on.  I'd figure the default (left-click)
action would be the first, opening it in a browser thingy.

> appropriate for these URIs?  This is an area where I think the mailto: URI
> might not be such a great model to follow, as it some ways it sits uneasily
> with other expectations of Web architecture.  (I've tried to avoid appealing
> to Web notions up to now, but I don't think that can be completely avoided,
> as URIs *are* probably the most fundamental technical underpinning of Web
> architecture, and I do think we should try not to create additional problems
> there.)

One could imagine directly sending email, opening a chat window, or
initiating a VoIP call to a single entry, if the entry has the
appropriate contact info (addresses, phone numbers).  In this sense,
it might step on mailto, xmpp, and tel URLs, but maybe it's that it
might "contain" such URLs, and be a level of indirection to them.  But
it's sort of like on my BlackBerry: when I click the menu button on an
addrbook entry, it offers things like "call Graham; SMS Graham; chat
with Graham; email Graham".

> operations like Add, Update and Delete might usefully be applied to such

I'm not suggesting that "add to address book" would be encoded in the
URI, but that it would be something the application could do with the
URI.  I'd imagine that a good app would get user approval after
showing the user what was going to happen.

> In summary, I find myself in the slightly uncomfortable position of liking
> the potential for what an addrbook: URI scheme might offer, but fearing that
> the immediate requirement coming from the Sieve protocol has too small a
> "contact area" with the URI to meaningfully shape the URI technical
> specification to be able to achieve those goals in later developments.

Does this help with that?
Do you have suggestions about what text we could add that would make
things better?

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Apr 2011 11:06:44 -0400

Hi Graham,

--On April 26, 2011 3:12:24 PM +0100 Graham Klyne <[email-masked]> 
wrote:

> In particular, concerning point (3), I think that an "add to address
> book" functionality encoded within a URI would be a Bad Thing.  But
> allowing that operations like Add, Update and Delete might usefully be
> applied to such URIs
>
> Another point about which I worry is the potential mismatch between being
> able to use such URIs as part of the process of, say, adding an entry to
> an address book, and in a context that allows "any URI that can be
> considered to resolve to some sort of list".  (But this maybe a probhlem
> for the Sieve protocol, not the proposed URI scheme.)
>
> In summary, I find myself in the slightly uncomfortable position of
> liking the potential for what an addrbook: URI scheme might offer, but
> fearing that the immediate requirement coming from the Sieve protocol has
> too small a "contact area" with the URI to meaningfully shape the URI
> technical specification to be able to achieve those goals in later
> developments.

Personally I think the "add to address book" use here is not right. 
addrbook: by itself does not include any actual contact data - it is simply 
a reference to an address book. "Add to addressbook" is handled (today) by 
simply providing a link to a vcard resource or use of a Link header point 
to vcard.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Apr 2011 11:44:17 -0400

Hi Barry,

> but it's possible for it to be > 1.  The fourth is specifying a single

OK, so now I am getting nervous too. What you have just sketched out above 
is an address book access API. I think this goes way beyond the scope of 
what was needed in SIEVE. It crosses the boundaries of a whole bunch of 
other protocols: CardDAV, LDAP, the W3C contacts api etc. Some of those 
already have URIs that can encode query strings (LDAP) so why are we going 
to re-invent the wheel here?

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 26 Apr 2011 11:50:23 -0400

> to re-invent the wheel here?

Well, none of that is invented yet.  That's just an idea I had, and
it's not written anywhere but here.  If folks don't think it's useful
(or even that it's bad), well, we won't write an extension draft for
it.  :-)

Maybe the extension bits will be used for other things instead.

Barry

---

From: Graham Klyne <[email-masked]>
Date: Tue, 26 Apr 2011 19:27:00 +0100

Barry,

This has moved on somewhat from my original point.  I think I'll need some time 
to review and digest the original background material and make a constructive 
response.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 26 Apr 2011 19:33:32 +0100

Cyrus Daboo wrote:
> Hi Barry,
> 
> --On April 26, 2011 11:17:32 AM -0400 Barry Leiba 
> <[email-masked]> wrote:
> 
> OK, so now I am getting nervous too. What you have just sketched out 
> above is an address book access API. I think this goes way beyond the 
> scope of what was needed in SIEVE. It crosses the boundaries of a whole 
> bunch of other protocols: CardDAV, LDAP, the W3C contacts api etc. Some 
> of those already have URIs that can encode query strings (LDAP) so why 
> are we going to re-invent the wheel here?

Yeah... :)  I had some vaguely similar thought ... why not have a localhost 
option for some existing scheme (similar to file:///)?  But on a brief skim I 
couldn't make the parts line up, so became less sure that was a viable approach.

So, reinvention aside, I think what Barry sketches above is prima facie a 
reasonable approach.  If there's any real advantage to an addrbook: scheme, I 
think it is in part that it can abstract away from a particular protocol or 
mechanism and leave just the essential capabilities exposed.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Apr 2011 16:25:17 -0400

> reasonable approach.  If there's any real advantage to an addrbook: scheme,
> I think it is in part that it can abstract away from a particular protocol
> or mechanism and leave just the essential capabilities exposed.

Graham, where are we on this?  Should we proceed with the Sieve
document as it is, with the addrbook URI?  Or do we still need more
discussion?  We're otherwise ready to send the document to the IESG.

Barry