SOGo 2.3.3a doesn't report contacts without email address

sillysausage

So I created two contacts.

BEGIN:VCARD
UID:5281-5657B880-1-2C1A198.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Joe Bloggs
FN:Joe Bloggs
EMAIL;TYPE=work:joeblogs@example.com
END:VCARD

and:

BEGIN:VCARD
UID:530C-5657B900-1-2A2FE6C0.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Sally Bloggs
FN:Sally Bloggs
END:VCARD

The full debug log is here:

[info ] Preparing synchronization
[info ] Querying capabilities
[trace] --> PROPFIND /SOGo/dav/fred@bloggsfamily.id/Contacts/personal/ HTTP/1.1
[trace] Depth: 0
[trace] <?xml version='1.0' encoding='UTF-8' ?><propfind xmlns="DAV:" xmlns:CAL="urn:ietf:par\
[trace] ams:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav"><prop><CARD:supported-\
[trace] address-data /><n0:getctag xmlns:n0="http://calendarserver.org/ns/" /></prop></propfi\
[trace] nd>
[trace] --> END PROPFIND (258-byte body)
[trace] <-- HTTP/1.1 207 Multi-Status (1525ms)
[trace] Server: nginx
[trace] Date: Fri, 27 Nov 2015 02:28:08 GMT
[trace] Content-Type: text/xml; charset="utf-8"
[trace] Content-Length: 478
[trace] Connection: keep-alive
[trace] X-Dav-Error: 200 No error
[trace] Ms-Author-Via: DAV
[trace] Pragma: no-cache
[trace] Cache-Control: no-cache
[trace] OkHttp-Selected-Protocol: http/1.1
[trace] OkHttp-Sent-Millis: 1448591287577
[trace] OkHttp-Received-Millis: 1448591287974
[trace] <?xml version="1.0" encoding="utf-8"?>
[trace] <D:multistatus xmlns:a="urn:ietf:params:xml:ns:carddav" xmlns:D="DAV:" xmlns:b="http:\
[trace] //calendarserver.org/ns/"><D:response><D:href>/SOGo/dav/fred@bloggsfamily.id/Contacts/p\
[trace] ersonal/</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><b:getctag>1\
[trace] 448591266</b:getctag></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 404 Not Fou\
[trace] nd</D:status><D:prop><a:supported-address-data/></D:prop></D:propstat></D:response></\
[trace] D:multistatus>
[trace] <-- END HTTP (478-byte body)
[debug] Received <response> for https://sogo.myserver.com/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/, status: null, properties: [getctag(http://calendarserver.org/ns/): GetCTag(cTag=1448591266),
supported-address-data(urn:ietf:params:xml:ns:carddav): null]
[info ] Server advertises VCard/4 support: false
[info ] Processing locally deleted entries
[info ] Locally preparing dirty entries
[info ] Uploading dirty entries
[info ] Checking sync state
[info ] Manual sync, ignoring CTag
[info ] Listing local entries
[debug] Found local resource: 5281-5657B880-1-2C1A198.vcf
[debug] Found local resource: 530C-5657B900-1-2A2FE6C0.vcf
[info ] Listing remote entries
[trace] --> REPORT /SOGo/dav/fred@bloggsfamily.id/Contacts/personal/ HTTP/1.1
[trace] Depth: 1
[trace] <?xml version='1.0' encoding='UTF-8' ?><CARD:addressbook-query xmlns="DAV:" xmlns:CAR\
[trace] D="urn:ietf:params:xml:ns:carddav"><prop><getetag /></prop><CARD:filter /></CARD:addr\
[trace] essbook-query>
[trace] --> END REPORT (184-byte body)
[trace] <-- HTTP/1.1 207 Multi-Status (385ms)
[trace] Server: nginx
[trace] Date: Fri, 27 Nov 2015 02:28:08 GMT
[trace] Content-Type: text/xml; charset="utf-8"
[trace] Content-Length: 761
[trace] Connection: keep-alive
[trace] Cache-Control: no-cache
[trace] Pragma: no-cache
[trace] OkHttp-Selected-Protocol: http/1.1
[trace] OkHttp-Sent-Millis: 1448591288114
[trace] OkHttp-Received-Millis: 1448591288487
[trace] <?xml version="1.0" encoding="utf-8"?>
[trace] <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"><D:response><D\
[trace] :href>/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/5281-5657B880-1-2C1A198.vcf</D:h\
[trace] ref><D:propstat><D:prop><D:getetag>"gcs00000000"</D:getetag><C:address-data>BEGIN:VCA\
[trace] RD
[trace] UID:5281-5657B880-1-2C1A198.vcf
[trace] VERSION:3.0
[trace] CLASS:PUBLIC
[trace] PROFILE:VCARD
[trace] N:;Joe Bloggs
[trace] FN:Joe Bloggs
[trace] EMAIL;TYPE=work:joeblogs@example.com
[trace] END:VCARD</C:address-data><C:addressbook-data>BEGIN:VCARD
[trace] UID:5281-5657B880-1-2C1A198.vcf
[trace] VERSION:3.0
[trace] CLASS:PUBLIC
[trace] PROFILE:VCARD
[trace] N:;Joe Bloggs
[trace] FN:Joe Bloggs
[trace] EMAIL;TYPE=work:joeblogs@example.com
[trace] END:VCARD</C:addressbook-data></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propst\
[trace] at></D:response></D:multistatus>
[trace] <-- END HTTP (761-byte body)
[debug] Ignoring unknown/unparseable property addressbook-data(urn:ietf:params:xml:ns:carddav)
[debug] Received <response> for https://sogo.myserver.com/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/5281-5657B880-1-2C1A198.vcf, status: null, properties: [address-data(urn:ietf:params:xml:ns:carddav): AddressData(vCard=BEGIN:VCARD
UID:5281-5657B880-1-2C1A198.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Joe Bloggs
FN:Joe Bloggs
EMAIL;TYPE=work:joeblogs@example.com
END:VCARD),
getetag(DAV:): GetETag(eTag=gcs00000000)]
[debug] Found remote VCard: 5281-5657B880-1-2C1A198.vcf
[info ] Comparing local/remote entries
[info ] 530C-5657B900-1-2A2FE6C0.vcf is not on server anymore, deleting
[info ] Downloading remote entries
[info ] Downloading 0 contacts (10 at once)
[info ] Saving sync state
[info ] Saving CTag=1448591266

rfc2822

There are multiple <C:address-data> elements in the same response, which doesn’t make any sense. Can you please report this problem to SOGo?
It’s a known SOGo problem that contacts without email address are/were not listed in the response. As far as I know, this has already been fixed.

sillysausage

There are multiple <C:address-data> elements in the same response, which doesn’t make any sense. Can you please report this problem to SOGo?

Okay I’ll do that. Filed at SOGo #3400

Summary: Multiple <C:address-data> elements are issued in the same response.
Description: paste of above input data and output trace

I don’t really know much about cardav/caldav.

It’s a known SOGo problem that contacts without email address are/were not listed in the response. As far as I know, this has already been fixed.

Well I’m running the latest SOGo 2.3.3a on CentOS, and it certainly still happens. That bug is still set to status new, maybe the change never got merged into 2.3.3?

rfc2822

@sillysausage said:

That bug is still set to status new, maybe the change never got merged into 2.3.3?

Perfectly possible. Maybe you can ask in that SOGo bug report?

kwirk

The missing entries issue hasn’t been fixed upstream yet. I’ve applied the change as mentioned in SOGo #3373 which fixes the issue, but I am still seeing the duplicate returns as now raised in SOGo #3400.

However, I think the “duplicate” entries is intentional, as there is a comment in the source code about compatibility; ‘address-data’ vs. ‘addressbook-data’. This doesn’t seem to have any adverse affects in DAVdroid.

rfc2822

@kwirk said:

However, I think the “duplicate” entries is intentional, as there is a comment in the source code about compatibility; ‘address-data’ vs. ‘addressbook-data’. This doesn’t seem to have any adverse affects in DAVdroid.

You’re right, I have read two times “addressbook-data” by mistake. However, I haven’t seen such a solution yet and it seems quite a waste of bandwidth? But you’re right, DAVdroid of course ignores unknown DAV properties.

jtg

This seems to have been fixed in SOGo 2.3.7.