Subject: Re: [lemonade] Proposal for addition and deletion of extensions to the Lemonade Profile Bis

From: Dan Karp <[email-masked]>
Date: Thu, 29 Nov 2007 05:34:45 -0800 (PST)

> Irrespective of the current METADATA spec, if there is any need to
> store meta-data-like information on the server then we should have
> one way to do that, rather than having each extension do its own
> thing.

There's a very specific, limited way that a client needs to query
the server to discover the server's CONVERT capabilities.  Ideally,
you want something as clear and as simple as possible to allow this.
Yes, you could shoehorn this into a general-purpose "metadata"
framework that returns a non-syntax-constrained octet stream to each
request, but that sounds a lot like a hydraulic jackhammer in search
of nails.  (And many of us don't own the jackhammer.)

If you want to argue for going down the latter route, we should first
look at 2 or 3 other serious proposed extensions that have a need for
similar client discovery behavior so that we can try to draw out the
commonalities.  If there aren't any such extensions or there aren't
major common needs, then we're looking at a CONVERT-specific issue
that should be dealt with within CONVERT rather than generalized.

(And I'm not completely sure that a server's CONVERT implementation
capabilities are "metadata" in the same way that, say, the MOTD is.)

> If there is a need for that, and there is a problem with complexity in
> the current METADATA spec, then lets address that. I certainly think
> revising the data model (e.g. doing away with .priv and .shared, fixing
> the content-type model etc) would one approach, as well as removing the
> dependency on LISTEXT (i.e. no searching for metadata values).

METADATA, as it stands now, is way too complicated.  It attempts to
be a read-write mailbox-level metadata store, a read-write server-
level metadata store, and a read-only extension capability discovery
mechanism.

The third of those seems to have been an afterthought, but it's why
METADATA is even in the Lemonade discussion.  I'm not convinced that
METADATA -- or anything like it -- is a good solution for the third
problem.  And, as I mentioned above, I'm not sure that the third
problem isn't just a CONVERT problem that needs to be dealt with
within CONVERT.

(If you want to talk about revamping METADATA as a mailbox-level
metadata repository, I'm happy to participate.  I'm of the opinion
that we could shed .priv/.shared, .value/.size, LIST-EXTENDED, vendor
space, and multi-level key hierarchy without losing the core METADATA
functionality.)

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Nov 2007 14:37:54 +0100

Dan Karp writes:
> METADATA, as it stands now, is way too complicated. It attempts to be 
> a read-write mailbox-level metadata store, a read-write server- level 
> metadata store, and a read-only extension capability discovery 
> mechanism.
>
> problem.

+1

Btw, this combination makes METADATA difficult for me to implement.

Arnt