Subject: [lemonade] Even more drastic cut-backs in METADATA

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Mar 2008 11:05:19 -0400

Hi,
So I have been thinking some more about the issue of removing attributes 
from METADATA. I think that will introduce some problems with how we can 
then do .priv and .shared. My original idea was to allow ".priv" and 
".shared" to be tacked on the end of an entry name to have the appropriate 
value returned. This is ugly in that it then requires the somewhat 
arbitrary restriction that entry names themselves cannot end in .priv or 
.shared.

So here is a more radical proposal: do away with .priv and .shared as well. 
Instead each annotation would define whether it is per-user or shared. So 
on a mailbox we would initially define:

/comment-public
/comment-private

Where "public" would be "shared" and "private" would be per-user.

-- 
Cyrus Daboo

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dan Karp <[email-masked]>
Date: Fri, 14 Mar 2008 08:12:34 -0700 (PDT)

> So here is a more radical proposal: do away with .priv and .shared as
> well.  Instead each annotation would define whether it is per-user or
> shared.  So on a mailbox we would initially define:
> 
>   /comment-public
>   /comment-private
> 

I really like this, as there are very, very few entries that are
meaningful as both private and public.

How does this affect the statement from section 3.3 of the old document:

   If the METADATA extension is present, support for shared annotations
   is REQUIRED, whilst support for private annotations is OPTIONAL.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Curtis King <[email-masked]>
Date: Fri, 14 Mar 2008 10:44:15 -0600

> Where "public" would be "shared" and "private" would be per-user.

I really like this idea.

ck

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 14 Mar 2008 13:26:25 -0400

Hi Dan,

>    is REQUIRED, whilst support for private annotations is OPTIONAL.

If server vendors still feel they need to have the option to deny per-user 
annotations, then we need to add some suitable response codes that would 
indicate lack of support for a registered per-user annotation.

Another thing: with this new approach there is no way for a client to 
create arbitrary (unregistered) entry names on a shared or per-user basis, 
given that the server determines what is shared and per-user based on 
registrations.

So perhaps we need a slight variant here:

/public/comment
/private/comment

With these two top-level entry segments, we have a clear distinction 
between what is shared and what is private. Registered annotations would 
have to define annotations in each as appropriate. Clients could create 
unregistered entries in either to achieve the behavior they need. A server 
that does not support per-user annotations simply does not support /private.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Mar 2008 21:45:36 +0000

>Where "public" would be "shared" and "private" would be per-user.
I really really really dislike that, as now there is no way to 
algorithmically determine which annotation is public and which one is 
private. Unless you meant that each annotation will have either 
"-public" or "-private"?
A better way would be to define two separate hierarchies: /public and 
/private, e.g. /private/comment.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Mar 2008 17:21:46 -0400

> that does not support per-user annotations simply does not support /private.

I'm a bit late with this comment, but: That variant works for me.

Barry