[Kolab-devel] No x-uid please. (was: Re: [NEW KEP] KEP #17: Kolab XML Format 3.0)

[Christian Mollekopf]

On 2012-03-13 1:18, Jeroen van Meeuwen (Kolab Systems) wrote:
> On 2012-03-12 17:15, Christian Mollekopf wrote:
>> On Monday 12 March 2012 15.40:53 Jeroen van Meeuwen wrote:
>>> On 2012-03-08 17:11, Christian Mollekopf wrote:
>>> > On 2012-03-08 18:00, Thomas Brüderli wrote:
>>> >> (...snip...)
>>> >
>>> > (...snip...)
>>>
>>> If I understand correctly, according to the xCard specification, 
>>> the
>>> member element to a distribution list is to contain a valid URI[1].
>>>
>>
>> Yes, the member can contain any valid uri including mailto, a urn
>> with the UID of another contact or an imap: uri pointing to a 
>> contact
>> resource.
>>
>>> What we seem to have done is we've gone outside of the boundaries 
>>> of
>>> the xCal specification and added an 'x-uid' attribute to the member
>>> element so that Kolab clients can use the values of the attribute 
>>> to
>>> get
>>> to the <uid> of the contact being referred to.
>>>
>>
>> Yes, we have extended it within the bounds of the xCards own
>> extension
>> mechanism, so the document remains valid xCard. It is however a
>> non-standard
>> property, but I don't think it's less interoperable than having imap
>> as the
>> default uri.
>>
>
> Arguing an extension to a standard is within the standard is
> misinterpreting the definition of the term "extension".
>
> The standard permits (arbitrary) extensions, but simply by permitting
> extensions, the standard does not make such extensions part of the
> standard.
>

Yes, agreed. It was just for clarification.

> We're probably going to need a few, but morphing a standard into our
> own version of said standard "just because" is not going to fly.
>

Agreed as well, I see x-uid as one we need though.

>>> This is supposed to resolve a problem people perceive to exist with
>>> referencing external contact entries, but goes about it the wrong
>>> way.
>>>
>>> The spec says the member attribute can contain a valid URI,
>>> including:
>>>
>>>    imap://imap.example.org/Contacts/SUBJECT%20<uid>
>>>
>>> For a client to retrieve the contact objects associated with a
>>> distribution list, nothing is gained by adding an x-uid attribute 
>>> to
>>> the
>>> member element over the use of an IMAP URI.
>>>
>>
>> The simplest usecase of a group is IMO an email distribution list.
>> This is the primary usecase we're serving using the mailto uri 
>> scheme
>> (hence also the
>> name).
>>
>> I went this route because it's very easy to implement for clients,
>> and is what the goup has been used for so far (Kontact and kolabV2).
>>
>> Because we acknowledge there are more advanced usecases where you
>> actually
>> want to get hold of the complete contact object, we introduced the
>> x-uid
>> attribute, serving that additional/optional usecase. Client's don't
>> need to
>> support that attribute to make all possible which has been so far,
>> but may, to retrieve the full contact object.
>
> This is exactly the type of circular reasoning we're trying to avoid
> applying to the format by ourselves.
>
> If a Kolab client aware of the meaning of an x-uid attribute value
> reads a distribution list object edited by a client that has no
> understanding of the x-uid attribute value, the behaviour between the
> two clients is going to be different.
>
> Remember we've been there before and it wasn't pretty.
>
> Different clients showing different behaviour, precedence rules,
> conflict detection between asynchronous edits and conflict resolving 
> all
> kick in here, and for no good reason.
>

No they don't, the behavior is very clear, there is no possibility for 
conflicts and we don't need precedence rules or conflict resolving.

There is a mailto uri which serves the purpose of having an email 
distribution list and is not directly connected to a contact. There is 
no need or desire to synchronize that to a Contact instance.
The x-uid property serves the additional purpose of being able to link 
a Contact object to that member, so it's easy to get to it. That is an 
additional usecase and there is no need to have the properties 
synchronized in any way.

If, and only if, clients would start to misuse an email address of a 
referenced Contact object as the email address for the distribution list 
purpose we woul run indeed in inconsistent behaviour, so there should 
define that clearly how the information MAY be used respectively MUST 
NOT.

If we have only an imap uri though, we have several other problems to 
solve:
- All clients need to be able to retrieve the imap object and find the 
correct email address for the distribution list purpose
- The location of the Contact object might change, breaking the link, 
leaving no chance to restore the link (except extracting the UID from 
the url, which seems a bit hacky)
- If we wanted to attach a Distribution List to i.e. a Word Document, 
the Contact might be available on the other side but not by the same 
imap uri. The mailto uri is location independent though (for the 
distlist usecase), and a link via URI to the Contact object works as 
well.
- We'd need to specify a mechanism for clients to figure out which of 
the available email addresses is to be used for the distlist usecase.

So IMO that requires much more behavioral rules and conflict resolution 
while complicating things on the client side. Also we'd likely would 
need another custom mechanism to specify which of the clients email 
addresses is to be used for the distlist usecase (because "preferred" 
won't work, that's something different IMO).

Do you understand my point, or am I just missing yours? I feel we're 
going a bit in circles here =P

Cheers,
Christian

> Kind regards,
>
> Jeroen van Meeuwen