| Summary | Horde seems to drop extended properties |
| Queue | Turba |
| Queue Version | Git master |
| Type | Bug |
| State | Not A Bug |
| Priority | 2. Medium |
| Owners | |
| Requester | play (at) bitfire (dot) at |
| Created | 2014-04-04 (2670 days ago) |
| Due | |
| Updated | 2014-04-12 (2662 days ago) |
| Assigned | |
| Resolved | 2014-04-07 (2667 days ago) |
| Milestone | |
| Patch | No |
break if it gets such properties, so you can consider them
supported. There is no mentioning of such properties having to be
kept and stored.
non-standard properties is that it must not break while it doesn't
need to process and store these properties?
cannot support this at the moment. This might be a feature request
for later versions.
requires it, but we can't/won't/don't want to do it". (But then it's
not compliant.)
break if it gets such properties, so you can consider them supported.
There is no mentioning of such properties having to be kept and stored.
Anyway, this still doesn't change the other reasons why we don't and
cannot support this at the moment. This might be a feature request for
later versions.
We simply don't support certain attributes. You can't synchronize
the same data from one client to many servers, but you will
synchronize the same data from one server to many clients. Thus the
server is the definite reference of contact information.
should support unknown/extended properties ("As a result, the client
will have to cache the entire set of properties on a resource that is
being changed." in section 9.1). For servers, you can read in section
6.3.2.2 [https://tools.ietf.org/html/rfc6352#section-6.3.2.2]:
parameters in address object resources stored via the PUT method.
simply don't support certain attributes. You can't synchronize the
same data from one client to many servers, but you will synchronize
the same data from one server to many clients. Thus the server is the
definite reference of contact information.
As per the ticket you referred to: it would be nice to keep unknown
properties from clients, but not doing so isn't a bug and the current
architecture of Turba doesn't allow this. Turba is NOT a vCard
storage, but an address book server that happens to import and export
to vCard.
#118[https://github.com/rfc2822/davdroid/issues/118]. It is explained and
discussed there why such behavior is a bug and why it makes
interoperability with other clients impossible/broken.
State ⇒ Not A Bug
theoretically configure Turba and add any custom fields, but the
mapping to vCard properties cannot be configured.
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Horde seems to drop extended properties
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
This might be OK, but common sense seems to be that all properties
(regardless of whether they make sense) should be kept to make people
happy.
Please see here: https://github.com/rfc2822/davdroid/issues/203
A related issue in DAVdroid: https://github.com/rfc2822/davdroid/issues/118