Return-Path: X-Original-To: jmap@mail2.ietf.org Delivered-To: jmap@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id EF79BDC7CB91 for ; Tue, 14 Apr 2026 21:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776228719; bh=Bq/imW38zXkssyUXthUsc+6VNEP7/BjHQZylNXTRmb8=; h=Date:From:To:In-Reply-To:References:Subject; b=MarAKXo8Irx1UKk0GsMOIy5bXtPFemjJBGL+BM5hvc+cr9f3QVRl+p7QA+sWbVYzg CWYbq4sEgGBYlAMaizpWi2ovH9N3qHS3WKCMxgZafsvOVL4T4buQ4dq/fqtZ93ehFq A6X0s+eDeLQdF+z2EGzvXcOXkHYnpwmg9woRjN2c= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="KL2Z56OI"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="I+ZOz+qT" Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KDs86MSLT4F for ; Tue, 14 Apr 2026 21:51:57 -0700 (PDT) Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id AFF43DC7CB11 for ; Tue, 14 Apr 2026 21:51:52 -0700 (PDT) Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 64379EC00C4 for ; Wed, 15 Apr 2026 00:51:45 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Wed, 15 Apr 2026 00:51:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1776228705; x= 1776315105; bh=x+QZcNofofb66WY8Pnjv7agb72lQx9N37HeBA5Wh6AI=; b=K L2Z56OIPUZRwWaUQJPLVNGM6Y9p3zx1CuN9NGHl3T027mofW8vAfkTKA6cWh9uhq MG0omBlz6N0A2a9wQwdmo7wr6UPXsThSSj0f2ihBVeAY+ljjOIClyh2hkXVm+qXU g3IJgV9agbPu48VOnlCt1ROXqZNNrMOEA1JYCSxuxg453RHN/knY4fDFgizEesn9 /SI7xD18ojQfKrVLT6cOUxi4pvueKPq0TiLL4pyp/eicOsC1sy8GByV5BCA5dmsN EqgHuqc1rptp1x/PibpesqqaMPiUyh4eJ+Pk0FVj+lr3stDJH+vEUvJX5S2tJkwg 3Xd+ivFnsdCrxFhLCEoIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1776228705; x=1776315105; bh=x+QZcNofofb66WY8Pnjv7agb72lQx9N37He BA5Wh6AI=; b=I+ZOz+qTROoa18tvrBIK0eGH4XnQxkNJDMAuTrtfTBsYTwI3A3Q PEP9ab/CA1LhxtBSk3Uj2HvdIG4V1EU0XceN0WVWpt7T2gLW7gOZnFkF6vQMqgSj o7Q7yuRVtVlJyKA25z/oJUlebdw8Vlqe6YS6u15t+BYrH6snUiAs1MZPIRC6hnuv oy/3gEnvD04ykkMFzmWbi+YFLzraPJuGlbA6rZtBBtqxi3md0CDCo9hKkGBYhlL0 MRhYhMTX0Gz8PY3C/GWunnsCcslDJmltAcAqIzF9mhVpIaLH94mkujEsGCtf83VY YswOnvFfh25tfPlWqLeyaKapnI3NIMHgbfw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdegfeduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdfpvghilhculfgv nhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtf frrghtthgvrhhnpeeijeevjedtgeejfeeluddtheekveeihffgueduteevueekgeetudeg ueffleeghfenucffohhmrghinhepihgvthhfrdhorhhgpdhfrghsthhmrghilhdrtghomh dprhhftgdqvgguihhtohhrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmpd hnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehjmhgr phesihgvthhfrdhorhhg X-ME-Proxy: Feedback-ID: ibc614277:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 1604A780070; Wed, 15 Apr 2026 00:51:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Wed, 15 Apr 2026 14:50:45 +1000 From: "Neil Jenkins" To: "JMAP IETF" Message-Id: <9e8b403c-e0d3-4af6-ac47-c1af06f27e1e@dogfoodapp.fastmail.com> In-Reply-To: <8397988B-24C5-42D7-BD1E-45CEDD009AC5@stalw.art> References: <8397988B-24C5-42D7-BD1E-45CEDD009AC5@stalw.art> Content-Type: multipart/alternative; boundary=6a26f77ea7d22c06368dfcfd8932afc2156f1737 Message-ID-Hash: WVSUFW7X6ITGQBUKWROVM5XINS5XQGRZ X-Message-ID-Hash: WVSUFW7X6ITGQBUKWROVM5XINS5XQGRZ X-MailFrom: neilj@fastmailteam.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BJMAP=5D_Re=3A_Status_of_JMAP_Metadata=2C_RefPlus_and_Mail_Shari?= =?utf-8?q?ng_drafts_ahead_of_IETF_125?= List-Id: JSON Meta Access Protocol Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --6a26f77ea7d22c06368dfcfd8932afc2156f1737 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've read through all of these again. > https://datatracker.ietf.org/doc/draft-ietf-jmap-mail-sharing/ This looks great, I think it should go to WG last call and be submitted = for publication. > https://datatracker.ietf.org/doc/draft-ietf-jmap-refplus/ My overall view of this is still that the added complexity (and executio= n performance concerns) of this outweighs the performance benefits of re= ducing a few extra round trips. I'm not objecting to the document moving= forward, but I'd love to see some evidence that someone has a real use = case for it. Regardless, some more specific concerns: **=C2=A71.2.1. The value of this property in the JMAP Session "accountCa= pabilities" property is an empty object.** I don't think the capability should be included in `accountCapabilities`= , just the top-level `capabilities`. These changes are not things within= a particular account; they apply at a higher level (like JMAP Core). (C= aveat, see comment on /set below.) * * **=C2=A72.2.1 The nodelist produced by JSON Path evaluation MUST be reso= lved according to the expected type of the target property** I *really* don't like this. Instead of being a pure syntactical transfor= mation, the dispatching server must now understand the full expected str= ucture of the method being called in order to apply the result reference= . This is a layering violation, and could be impossible for a generic JM= AP proxy that doesn't understand (or need to understand) the actual meth= od calls it's dispatching to JMAP servers downstream. (Yes, I saw later in =C2=A73.1 you say *"The type-specific resolution ru= les defined in this specification (determining whether a resolved value = should be treated as a single value, an array, or a map) are applied by = the JMAP method implementation layer, not by the reference resolution la= yer."* =E2=80=94 that's still requiring support at multiple layers.) Instead, why not add an extra `type` property to the ResultReference obj= ect that gives the expected type? The caller should know what they expec= t this to resolve to, and that means the reference resolver doesn't need= to know. This lets everything be done at the Syntactic Resolution Phase= (per =C2=A73.2). **=C2=A72.3 Usage in /set Methods** I think we need to explicitly state that should you opt in to the refplu= s capability you *cannot *set a property within a Foo object that beings= with a literal `#`. This is not a problem with any of the data types be= ing used with JMAP so far (as far as I'm aware), but worth noting for th= e future. (If for some reason a client *does* need to do this in the fut= ure, they must not include the refplus capability in the `using` array o= f the Request object; as per RFC8620, if not explicitly opted in, the se= rver must not apply the capability.) **=C2=A72.3**** If a result reference fails to resolve, the server MUST = reject the creation or update of that specific object with a SetError of= type "invalidResultReference"** This is problematic, because it means the resolution has to happen at me= thod execution time, rather than at method dispatch time. I don't think = it's necessary: we can resolve the references before dispatch and reject= the whole method with `invalidResultReference` if any fail. That's cons= istent with all the other result reference resolution, and means it can = be handled in the same layer. Otherwise, if we really want to keep the currently specified behaviour, = I think we will need to add the refplus capability to the `accountCapabi= lities` of accounts that support using ResultReferences inside `/set` cr= eate/update. Again, in the proxy case it may not be all of them. > https://datatracker.ietf.org/doc/draft-ietf-jmap-metadata/ I think this is looking fairly solid. A few comments: **=C2=A72.1.2 Servers SHOULD document whether they provide read-only or = read-write access to ImapMetadata.** **=C2=A72.1.3 **Servers SHOULD document whether they provide read-only o= r read-write access to WebDavMetadata.**** Why not put this in the capabilities? **=C2=A7***3.1 "alreadyExists" SetError [=E2=80=A6] MAY include an "exis= tingId" property containing the id of the existing Metadata object.* I'd change this MAY to a MUST =E2=80=94 it's easy to implement, and if i= t's only a MAY a client can't rely on it, which is a pain. (As a general= rule,=20 **=C2=A74.1 The response to an extended /get method includes the followi= ng additional property** I think we probably need to include `metadataState` in the response as w= ell? ** ** **=C2=A74.2.1 Servers SHOULD NOT generate [=E2=80=A6] state changes for = automatically deleted metadata. The deletion is considered an implicit c= onsequence of destroying the related object. However, servers MAY emit p= ush notifications or update metadata state strings to reflect that metad= ata has been deleted, if such notifications would otherwise occur for ex= plicitly deleted metadata.** I'm not quite sure what you're going for here. Surely the metadata state= *has* to change if a metadata object is destroyed, regardless of how th= is happened. Otherwise, the `/changes` updates won't work correctly. Related, the document doesn't currently specify that changes purely to a= Metadata object SHOULD NOT change the state string for the related type= , but I think that's the idea. Although=E2=80=A6 *Is this the right approach?* With my client implementer hat on, I was thinking about how I would want= to use metadata. Generally, I'd want to be able to say "I'm interested = in metadata for this particular type" and then fetch/update it with the = instances of that type themselves. I can't think of a circumstance where= I'd want metadata without the related object, but I could definitely ju= st have a small subset of the dataset for a particular object (e.g. I ha= ve loaded 100 emails for a user with 1,000,000 messages). The current ap= proach is a bit painful: =E2=80=A2 I can fetch the metadata with the Email objects by using the = *fetchMetadata* argument. Fine. =E2=80=A2 The Metadata state changes. I call `Metadata/changes` with *f= ilterRelatedType* set to `"Email"`. I can ignore any *updated* metadata = objects I don't have, but I have to always fetch the *created* metadata = objects, as I have no way of knowing if they're related to the Email obj= ects I currently have in memory or not. =E2=80=A2 I can't search for a Foo object that has some particular meta= data AND a regular property (e.g. if I used metadata to store a memo on an Email, and wanted to searc= h for all emails that are in the inbox and have a memo with the text "fo= o"). A very different approach would be: =E2=80=A2 Data types with metadata support (as per the capabilities) ge= t a mutable `_metadata_: String[*]` property if you opt in to the capabi= lity. We could have a `_private_metadata_` property too for private meta= data, if supported (per the capability).=20 =E2=80=A2 The value of this property is a (possibly empty) object (neve= r null so you can always patch). The keys at the top level are registere= d, or a domain name: =E2=80=A2 `imap`: maps to IMAP metadata =E2=80=A2 `webdav`: maps to WebDAV metadata =E2=80=A2 `example.com`: maps to arbitrary vendor data. =E2=80=A2 The metadata property can be specified in the *properties* ar= gument to `Foo/get`, like any other property. If you don't specify any p= roperties, it will be returned with the default set of properties (norma= lly everything) for that data type. (Or maybe we'd need a way to say "gi= ve me all the default properties, but *not* the metadata properties for = this object type"?) =E2=80=A2 `Foo/changes` returns objects where the `_metadata_` property= has changed in the *updated* argument of the response. We add an *updat= edProperties* argument to the response, like in Mailbox/changes . If only metadata has = changed, the server should use this to indicate that, so you can then on= ly fetch the metadata property. Possibly we add an extra argument to `Fo= o/changes` to ignore metadata-only changes for data types where you're n= ot interested in the metadata. =E2=80=A2 We define some extensions to the `Foo/query` FilterCondition = for any data type that supports metadata: =E2=80=A2 the presence of metadata at a particular path, e.g., `{"met= adataExists": "fastmail.com/memo"}` =E2=80=94 this matches any object wh= ere it has a value defined at that path. =E2=80=A2 text match at a particular path. e.g., `{"metadataText": { = path: "fastmail.com/memo", value: "foo"}` =E2=80=94 looks for a string i= n the property at a particular path. Is false if the path doesn't exist = or isn't a string type. =E2=80=A2 That's =E2=80=A6 kind of it? You can use standard `Foo/set` p= atching to update specific metadata properties without stomping on other= vendors=E2=80=99 metadata. You always keep your metadata in sync with t= he underlying objects. You don't really need to change any code in the c= lient, and all existing sync code will just work. Thoughts? This seems both simpler and more functional to me, and I don't= see any obvious drawbacks at first glance. Cheers, Neil. --6a26f77ea7d22c06368dfcfd8932afc2156f1737 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I've read th= rough all of these again.

=


M= y overall view of this is still that the added complexity (and execution= performance concerns) of this outweighs the performance benefits of red= ucing a few extra round trips. I'm not objecting to the document moving = forward, but I'd love to see some evidence that someone has a real = use case for it. Regardless, some more specific concerns:

=
=C2=A71.2.1. The value of this property in the JMA= P Session "accountCapabilities" property is an empty object.
=

I don't think the capability should be include= d in accountCapabilities, just the top-level capabilities. These changes are not things within= a particular account; they apply at a higher level (like JMAP Core). (C= aveat, see comment on /set below.)

=C2=A72.2.1 The nodelist produced by JSON Path evaluation MUST be = resolved according to the expected type of the target property

I really don't like this. Instead of bein= g a pure syntactical transformation, the dispatching server must now und= erstand the full expected structure of the method being called in order = to apply the result reference. This is a layering violation, and could b= e impossible for a generic JMAP proxy that doesn't understand (or need t= o understand) the actual method calls it's dispatching to JMAP servers d= ownstream.

(Yes, I saw later in =C2=A73.1 you s= ay "The type-specific resolution rules defined in this specification = (determining whether a resolved value should be treated as a single valu= e, an array, or a map) are applied by the JMAP method implementation lay= er, not by the reference resolution layer." =E2=80=94 that's still r= equiring support at multiple layers.)

Instead, = why not add an extra type property to the Resul= tReference object that gives the expected type? The caller should know w= hat they expect this to resolve to, and that means the reference resolve= r doesn't need to know. This lets everything be done at the Syntactic Re= solution Phase (per =C2=A73.2).

=C2=A72.3= Usage in /set Methods

I think we need = to explicitly state that should you opt in to the refplus capability you=  cannot set a property within a Foo object that beings = with a literal #. This is not a problem with an= y of the data types being used with JMAP so far (as far as I'm aware), b= ut worth noting for the future. (If for some reason a client doe= s need to do this in the future, they must not include the refp= lus capability in the using array of = the Request object; as per RFC8620, if not explicitly opted in, the serv= er must not apply the capability.)

=C2=A7= 2.3 If a result reference fails to resolve, the serve= r MUST reject the creation or update of that specific object with a SetE= rror of type "invalidResultReference"

T= his is problematic, because it means the resolution has to happen at met= hod execution time, rather than at method dispatch time. I don't think i= t's necessary: we can resolve the references before dispatch and reject = the whole method with invalidResultReference if= any fail. That's consistent with all the other result reference resolut= ion, and means it can be handled in the same layer.

=
Otherwise, if we really want to keep the currently specified behavi= our, I think we will need to add the refplus capability to the accountCapabilities of accounts that support u= sing ResultReferences inside /set create/update= . Again, in the proxy case it may not be all of them.


<= /div>
I think this is looking fairly solid. A few comments:

=C2=A72.1.2 Servers SHOULD document whether they = provide read-only or read-write access to ImapMetadata.
=C2=A72.1.3 Servers SHOULD document whether they pro= vide read-only or read-write access to WebDavMetadata.

Why not put this in the capabilities?

=C2=A73.1 "alreadyExists" SetError [=E2= =80=A6] MAY include an "existingId" property containing the id of the ex= isting Metadata object.

I'd change this MAY= to a MUST =E2=80=94 it's easy to implement, and if it's only a MAY a cl= ient can't rely on it, which is a pain. (As a general rule, 
<= div>
=C2=A74.1 The response to an extended /get= method includes the following additional property

I think we probably need to include me= tadataState in the response as well?

=
=C2=A74.2.1 Servers SHOULD NOT generate [=E2=80=A6= ] state changes for automatically deleted metadata. The deletion is cons= idered an implicit consequence of destroying the related object. However= , servers MAY emit push notifications or update metadata state strings t= o reflect that metadata has been deleted, if such notifications would ot= herwise occur for explicitly deleted metadata.
I'm not quite sure what you're going for here. Surely the me= tadata state has to change if a metadata object is dest= royed, regardless of how this happened. Otherwise, the /changes updates won't work correctly.

=
Related, the document doesn't currently specify that changes purely= to a Metadata object SHOULD NOT change the state string for the related= type, but I think that's the idea. Although=E2=80=A6

Is this the right approach?

With = my client implementer hat on, I was thinking about how I would want to u= se metadata. Generally, I'd want to be able to say "I'm interested in me= tadata for this particular type" and then fetch/update it with the insta= nces of that type themselves. I can't think of a circumstance where I'd = want metadata without the related object, but I could definitely just ha= ve a small subset of the dataset for a particular object (e.g. I have lo= aded 100 emails for a user with 1,000,000 messages). The current approac= h is a bit painful:
  • I can fetch the metadata with the Email= objects by using the fetchMetadata argument. Fine.
  • = The Metadata state changes. I call Metadata/changes with filterRelatedType set to "Email"= . I can ignore any updated metadata objects I don't h= ave, but I have to always fetch the created metadata objects, as = I have no way of knowing if they're related to the Email objects I curre= ntly have in memory or not.
  • I can't search for a Foo object = that has some particular metadata AND a regular property (e.g. if I used= metadata to store a memo on an Email, and wanted to search for all emails that ar= e in the inbox and have a memo with the text "foo").
A ver= y different approach would be:
  • Data types with metadata sup= port (as per the capabilities) get a mutable _metadata= _: String[*] property if you opt in to the capability. We co= uld have a _private_metadata_ property too for = private metadata, if supported (per the capability). 
  • The v= alue of this property is a (possibly empty) object (never null so you ca= n always patch). The keys at the top level are registered, or a domain n= ame:
    • imap: maps to IMAP metadata
    • webdav: maps to WebDAV metadata
    • <= code style=3D"border-top-width:1px;border-top-style:solid;border-top-col= or:rgb(204, 204, 204);border-right-width:1px;border-right-style:solid;bo= rder-right-color:rgb(204, 204, 204);border-bottom-width:1px;border-botto= m-style:solid;border-bottom-color:rgb(204, 204, 204);border-left-width:1= px;border-left-style:solid;border-left-color:rgb(204, 204, 204);border-i= mage-outset:0;border-image-repeat:stretch;border-image-slice:100%;border= -image-source:none;border-image-width:1;border-top-left-radius:3px;borde= r-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left= -radius:3px;background-color:rgb(246, 246, 246);background-position-x:0%= ;background-position-y:0%;background-repeat:repeat;background-attachment= :scroll;background-image:none;background-size:auto;background-origin:pad= ding-box;background-clip:border-box;font-family:menlo, consolas, monospa= ce;font-size:90%;padding-top:1px;padding-right:3px;padding-bottom:1px;pa= dding-left:3px;">example.com: maps to arbitrary vendor data.
      • =
  • The metadata property can be specified in the properties= argument to Foo/get, like any other property. = If you don't specify any properties, it will be returned with the defaul= t set of properties (normally everything) for that data type. (Or maybe = we'd need a way to say "give me all the default properties, but not the metadata properties for this object type"?)
  • Foo/changes returns objects where the _metadata_ property has changed in the updated argum= ent of the response. We add an updatedProperties argument to the = response, like in Mailbox/changes. If only metadata has changed, the ser= ver should use this to indicate that, so you can then only fetch the met= adata property. Possibly we add an extra argument to F= oo/changes to ignore metadata-only changes for data types where y= ou're not interested in the metadata.
  • We define some extensions = to the Foo/query FilterCondition for = any data type that supports metadata:
    • the presence of metada= ta at a particular path, e.g., {"metadataExists": "fas= tmail.com/memo"} =E2=80=94 this matches any object where it has a= value defined at that path.
    • text match at a particular path. e.= g., {"metadataText": { path: "fastmail.com/memo",= value: "foo"} =E2=80=94 looks for a string in the property = at a particular path. Is false if the path doesn't exist or isn't a stri= ng type.
  • That's =E2=80=A6 kind of it? You can use standard = Foo/set patching to update specific metadata pr= operties without stomping on other vendors=E2=80=99 metadata. You always= keep your metadata in sync with the underlying objects. You don't reall= y need to change any code in the client, and all existing sync code will= just work.
Thoughts? This seems both simpler and more fun= ctional to me, and I don't see any obvious drawbacks at first glance.

Cheers,
Neil.
--6a26f77ea7d22c06368dfcfd8932afc2156f1737--