Subject: Re: [sieve] I-D Action:draft-ietf-sieve-external-lists-07.txt

From: Barry Leiba <[email-masked]>
Date: Fri, 6 May 2011 16:33:05 -0400

> In response to review on the uri-review list, I have changed the URI
> schema name from "ab" to "addrbook".

In further discussion on the uri-review list, Graham, who will be the
expert reviewer we'll have to convince when we get to that point, has
pushed back on our defining an "addrbook" URI scheme for this.  At the
moment, he's not speaker as the expert reviewer, but this tells us
where we'll stand when he does.  It's still possible for us to
convince him, but for now, he's not convinced.

He suggests that we we use the "urn" scheme, either coming in as part
of the existing IETF parameter namespace:
   urn:ietf:param:sieve:addrbook:default
...or defining and registering our own new namespace:
   urn:addrbook:default

We're concerned that the former generates too-long and too-ugly URIs
for our purposes.  The second is possible, but I actually think it's a
*worse* idea to define a URN namespace for "addrbook" than it is to
make a URI scheme for it.

For those who want to see the discussions, here are the three most
significant posts from Graham:
   http://www.ietf.org/mail-archive/web/uri-review/current/msg01408.html
   http://www.ietf.org/mail-archive/web/uri-review/current/msg01416.html
   http://www.ietf.org/mail-archive/web/uri-review/current/msg01424.html

...and you can look at the other, related messages.

I spoke with Pete Resnick, who suggested using something related to
CardDAV to handle this.  I've asked Cyrus whether there's anything we
can do in that regard, and I'm waiting for his response.  Pete is not
inclined to go against Graham's recommendation, and also is concerned
about the scope here.

At this point, I don't know what to do, so I'm taking it back to the
working group.  Alexey thinks grabbing a URN namespace is acceptable,
even if we have to hold our noses a bit.  Ned, what do you think?
Others?

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 06 May 2011 21:42:43 -0400

Hi Barry,

> inclined to go against Graham's recommendation, and also is concerned

I will give you my response here: there is not a specific URL for CardDAV - 
it is just HTTP/WebDAV at its core so the only URLs that make sense are 
http and https. That does not fit our requirements.

> even if we have to hold our noses a bit.  Ned, what do you think?

Here is one possibility: change the syntax to provide for a prefix to the 
list name. The following could be used:

- "URL:" - what follows is a URL (as per current spec behavior)
- "list:" - a "generic" named list
- "ab:" - a list of addresses

So ab: and list: allow for a very compact identifier in line with what we 
wanted before, and we still can use URLs via the URL: prefix (at the 
expense of an additional 4 characters). That would allow us to remove the 
new URL registration we currently have.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 08:51:09 -0400

> it is just HTTP/WebDAV at its core so the only URLs that make sense are http
> and https. That does not fit our requirements.

That's what I thought, and what I found from looking at the docs, but
I wanted to be sure.  OK.

> - "ab:" - a list of addresses

That's very much like the idea we passed through, of using a registry
of our own for names that could be alternatives to a URI for that.  I
propose, though, that we not use a prefix in general, but instead
prefix the non-URIs with ":" (think of it as a "null URI scheme",
maybe).  So URIs could be exactly as they are now, and we'd have
   ":addressbook:default"
   ":addressbook:personal"
   ":addressbook:company?dept=2y5f"
for example, for our own names.  We can define a registry for these
names, specifying that everything after the second ":" be defined in
the definition of each name.

If Alexey and Ned think this is a good idea, I'll re-work the doc to
define the new registry, and we can do another quick WGLC on it before
we send it to the IESG.

Barry

---

From: Dave Cridland <[email-masked]>
Date: Sat, 07 May 2011 16:55:27 +0100

> define the new registry, and we can do another quick WGLC on it  

Isn't that URNs by the back door, though?

If so, what you could reasonably do is land-grab a URN prefix and  
then use that form as a shortcut to it. Then you don't even need a  
registry.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Sat, 07 May 2011 17:12:47 +0100

On Sat May  7 17:07:38 2011, Barry Leiba wrote:
> Yes, I suppose it is, at that.  Sigh.
> 
> then use
> > that form as a shortcut to it. Then you don't even need a  
> registry.
> 
> Still need a registry if we want to allow things other than
> "addrbook".  But, yes, if not, we don't.

Do you? I think you get to piggyback on the existing URN registry,  
essentially.

So the URNs would be of the form  
urn:ietf:params:protocols:biscuit-tin:elephant:sieve:addrbook?foo=bar, 
but the ":" prefix would expand into the urn:ietf bit all the way up  
to sieve.

Do you need a new registry for sub-trees?

Dave.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 12:07:38 -0400

> If so, what you could reasonably do is land-grab a URN prefix and then use
> that form as a shortcut to it. Then you don't even need a registry.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sat, 7 May 2011 12:33:12 -0400

> urn:ietf:params:protocols:biscuit-tin:elephant:sieve:addrbook?foo=bar,but
> the ":" prefix would expand into the urn:ietf bit all the way up to sieve.

Oh, hey, wait, I *like* that; it's an aspect I didn't think of that
solves two problems:

Problem 1: I think urn:ietf:params:sieve:addrbook:default is ugly and annoying.
Problem 2: I think registering a top-level URN namespace
(urn:addrbook) is silly.

We can get "urn:ietf:params:sieve:addrbook", and document that
":addrbook" is shorthand for that.  That is, we can say that a leading
":" expands to "urn:ietf:params:sieve:".

I like that.  Comments from others?

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 7 May 2011 15:03:07 -0400

Works for me.

-- 
Cyrus Daboo
(Tapped out on my iPad)

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 May 2011 10:11:22 -0400

> Works for me.

Great.  I'd like to hear assent from Alexey and Ned before I make the
changes.  If they agree, I'll put it in and submit an -08 version.

Barry

---

From: [email-masked]
Date: Sun, 08 May 2011 08:35:59 -0700 (PDT)

> changes.  If they agree, I'll put it in and submit an -08 version.

My main concern here is that the identifier be short and comprehensible, and
this seems to qualify. I really don't care what punctuation surrounds it as
long as it's simple, and this proposal works in that regard as well.

And while I'm happy we can finesse this particular case by using some syntax
and semantic tricks, I have to point out that some of the assertions made in
reviewing the original URL scheme proposal were quite simply wrong,  and it's
exactly the sort of mistake the IETF makes on a depressingly regular basis. 

In particular, the original response to this registration stated that:

  The use and deployment of new URI schemes in the Internet infrastructure is
  costly

This is of course true in the sense that widespread deployment in mutiple
protocols and applications is costly. But that's not what we were trying to do
and the assumption that this is what everyone who registers a URI scheme (or
media type or charset or whatever) is doing is nonsensical.

We were trying to define a mechanism for use in a single context in a single
protocol. If other protocols decided the mechanism made sufficient sense to
adopt, great, but if not that's fine too. Identifiers are cheap.

So again, being able to finesse the issue here is good. But sooner or later
we're going to have to face up to the fact that our, I guess I'd call it
registration philosophy, is increasingly at odds with how protocols are
actually defined and used.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 May 2011 12:57:44 -0400

>  The use and deployment of new URI schemes in the Internet infrastructure is
...

Indeed, and that's what I was getting at when I said this:
> The second is possible, but I actually think it's a

I don't see the harm to the Internet, to the registry, or to the
concept of URIs of being fairly free in approving new URI schemes.
But unless we rev BCP 115 (RFC 4395), that won't change.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 May 2011 16:57:54 +0100

>long as it's simple, and this proposal works in that regard as well.
I am Ok with it as well.

>media type or charset or whatever) is doing is nonsensical.
+1.

>actually defined and used.
Agreed.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 09 May 2011 12:17:08 -0400

Hi Alexey,

--On May 9, 2011 4:57:54 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>> My main concern here is that the identifier be short and comprehensible,
>> and this seems to qualify. I really don't care what punctuation
>> surrounds it as long as it's simple, and this proposal works in that
>> regard as well.
>>
>>
> I am Ok with it as well.

OK, then once Barry updates the spec I will ask for one more week of review 
by the working group to ensure the changes are OK, then we can move ahead 
with submission to the IESG.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 12:23:01 -0400

> with submission to the IESG.

I'll try to get the changes done today or tomorrow.

Barry