6.0.0-git
2021-04-15

[#13098] Horde seems to drop extended properties
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 (2568 days ago)
Due
Updated 2014-04-12 (2560 days ago)
Assigned
Resolved 2014-04-07 (2565 days ago)
Milestone
Patch No

History
2014-04-12 08:21:41 play (at) bitfire (dot) at Comment #7 Reply to this comment
It doesn't explain what "must support" means though. Turba doesn't 
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.
Really? Your interpretation of a standard, saying it "MUST support" 
non-standard properties is that it must not break while it doesn't 
need to process and store these properties?
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.
That's absolutely OK. I think that it's also OK to say "the standard 
requires it, but we can't/won't/don't want to do it". (But then it's 
not compliant.)
2014-04-08 09:23:44 Jan Schneider Comment #6 Reply to this comment
It doesn't explain what "must support" means though. Turba doesn't 
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.
2014-04-08 08:37:56 play (at) bitfire (dot) at Comment #5 Reply to this comment
Horde is the server, not the client, so the arguments don't apply. 
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.
In my recherches in RFC 6352, I could find only hints that clients 
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]:
   Servers MUST support the use of non-standard properties and
   parameters in address object resources stored via the PUT method.
If I understand this correctly, there's very little scope of interpretation.
2014-04-08 08:20:48 Jan Schneider Comment #4 Reply to this comment
Horde is the server, not the client, so the arguments don't apply. 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.
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.
2014-04-07 18:48:58 jkufner (at) gmail (dot) com Comment #3 Reply to this comment
Please read discussion about DavDroid issue #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.
2014-04-07 13:11:25 Jan Schneider Comment #2
State ⇒ Not A Bug
Reply to this comment
Turba doesn't and cannot store arbitrary unknown fields. You can 
theoretically configure Turba and add any custom fields, but the 
mapping to vCard properties cannot be configured.
2014-04-04 19:23:45 play (at) bitfire (dot) at Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Horde seems to drop extended properties
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
Reply to this comment
Horde seems to drop extended properties when updating a VCard.

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

Saved Queries