Copyright (C) 2008 Collabora Limited Copyright (C) 2008 Nokia Corporation

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

(as stable API) The name of the field; this is the lowercased name of a vCard field. For example, a field representing a contact's address would be named "adr".

A list of vCard type parameters applicable to this field, with their values. The type parameter names, and any values that are case-insensitive in vCard, MUST be in lower case. For example, a contact's preferred home address would have parameters 'type=home' and 'type=pref'.

The type parameter 'type' is likely to be the most common, but there can be others, such as 'language=en'.

Characters which are required to be escaped in vCard type parameters should not be escaped in this list. For instance, a field "X-FOO;SEMICOLON=\;:bar" in a vCard would become ('x-foo', ['semicolon=;'], ['bar']) in this interface.

This avoids Telepathy UIs having to understand the escaping and unescaping rules for vCards. The type parameter name is not allowed (by RFC 2425) to contain an '=' character, so no ambiguity is introduced.

For unstructured vCard fields (such as 'fn', a formatted name field), a single-element array containing the field's value.

For structured fields (such as 'adr', an address field), an array corresponding to the semicolon-separated elements of the field (with empty strings for empty elements).

A vCard field with multiple comma-separated values, such as 'nickname', should be represented by several Contact_Info_Fields.

Characters which are required to be escaped in vCard values, such as semi-colons and newlines, should not be escaped in this list (e.g. if a value contains a newline, the data passed over D-Bus should contain a literal newline character).

An earlier draft of this interface split structured vCard fields into multiple Telepathy-level fields; for example, 'n' became 'family-name', 'given-name', etc. But under this representation, omitting empty components leads to difficulty identifying where one name ends and another begins. Consider the fields ['given-name', 'honorific-suffixes', 'family-name', 'honorific-prefixes']: does this represent two 'n' fields, or one with incorrect component ordering?

Represents one piece of information about a contact, as modelled by a single vCard field. Of the fields defined in RFC 2426, common examples include:

fn
The contact's full name, formatted to their liking
n
The contact's full name, divided into five parts: family name, given name, additional names, honorific prefixes, and honorific suffixes
org
The contact's organisation, divided into the organization's name possibly followed by one or more organizational unit names.
adr
A street address for the contact, divided into seven components: post office box, extended address, street address, locality (e.g., city), region (e.g., state or province), the postal code, and the country name.
label
A free-form street address for the contact, formatted as a single value (with embedded newlines where necessary) suitable for printing on an address label
tel
A telephone number for the contact.
email
An email address for the contact.

For example, the following vCard:

   BEGIN:vCard
   VERSION:3.0
   FN:Wee Ninja
   N;LANGUAGE=ja:Ninja;Wee;;;-san
   ORG:Collabora, Ltd.;Management Division;Human Resources\; Company Policy Enforcement
   ADR;TYPE=WORK,POSTAL,PARCEL:;;11 Kings Parade;Cambridge;Cambridgeshire
    ;CB2 1SJ;UK
   LABEL;TYPE=WORK,POSTAL,PARCEL:11 Kings Parade\nCambridge\nCambridgeshire\nUK\nCB2 1SJ
   TEL;TYPE=VOICE,WORK:+44 1223 362967, +44 7700 900753
   EMAIL;TYPE=INTERNET,PREF:wee.ninja@collabora.co.uk
   EMAIL;TYPE=INTERNET:wee.ninja@example.com
   URL:http://www.thinkgeek.com/geektoys/plush/8823/
   NICKNAME:HR Ninja,Enforcement Ninja
   END:vCard

would be represented by (in Python-like syntax):

[
  ('fn', [], ['Wee Ninja']),
  ('n', ['language=ja'], ['Ninja', 'Wee', '', '', '-san']),
  ('org', [], ['Collabora, Ltd.', 'Management Division',
    'Human Resources; Company Policy Enforcement']),
  ('adr', ['type=work','type=postal','type=parcel'],
   ['','','11 Kings Parade','Cambridge', 'Cambridgeshire','CB2 1SJ','UK']),
  ('label', ['type=work','type=postal','type=parcel'],
   ['''11 Kings Parade
  Cambridge
  Cambridgeshire
  UK
  CB2 1SJ''']),
  ('tel', ['type=voice','type=work'], ['+44 1223 362967']),
  ('tel', ['type=voice','type=work'], ['+44 7700 900753']),
  ('email', ['type=internet','type=pref'], ['wee.ninja@collabora.co.uk']),
  ('email', ['type=internet'], ['wee.ninja@example.com']),
  ('url', [], ['http://www.thinkgeek.com/geektoys/plush/8823/']),
  ('nickname', [], ['HR Ninja']),
  ('nickname', [], ['Enforcement Ninja'])
]
A dictionary whose keys are contact handles and whose values are contact information.. An integer handle for the contact whose info has changed. An array of fields representing information about this contact. Emitted when a contact's information has changed or been received for the first time on this connection. An array of handles representing contacts. A dictionary mapping contact handles to information, whose keys are the subset of the requested list of handles for which information was cached. Request information on several contacts at once. This SHOULD only return cached information, omitting handles for which no information is cached from the returned map. Integer handles for contacts. Retrieve information for the given contact, requesting it from the network if an up-to-date version is not cached locally. This method SHOULD return immediately, emitting ContactInfoChanged when the contacts' updated contact information is returned. This method allows a client with cached contact information to update its cache after a number of days. An integer handle for a contact. Information about that contact. Retrieve information for a contact, requesting it from the network if it is not cached locally. This method is appropriate for an explicit user request to show a contact's information; it allows a UI to wait for the contact info to be returned. The contact's information could not be retrieved. Set new contact information for this connection, replacing existing information. This method is only suppported if ContactInfoFlags contains Can_Set, and may only be passed fields conforming to SupportedFields. The new information to be set. Setting your own information is not supported on this protocol. The supplied fields do not match the restrictions specified by SupportedFields. Flags defining the behaviour of contact information on this protocol. Some protocols provide no information on contacts without an explicit request; others always push information to the connection manager as and when it changes. Indicates that SetContactInfo is supported on this connection. Indicates that the protocol pushes all contacts' information to the connection manager without prompting. If set, ContactInfoChanged will be emitted whenever contacts' information changes. A string naming a field in a vCard, such as "fn" or "adr". Although these are case-insensitive in RFC 2425, in Telepathy they MUST be normalized to lower case. In the terminology of RFC 2425 this is called a "type name", and corresponds to the "name" production given in the ABNF. A type parameter as defined by RFC 2426, such as "type=cell" or "language=en".

An integer representing the bitwise-OR of flags on this connection.

This property MAY change, without change notification, at any time before the connection moves to status Connection_Status_Connected. It MUST NOT change after that point.

Some XMPP servers, like Facebook Chat, do not allow the vCard to be changed (and so would not have the Can_Set flag). Whether the user's server is one of these cannot necessarily be detected until quite late in the connection process.

A struct describing a vCard field, with parameters, that may be passed to SetContactInfo on this Connection. A vCard field name, such as 'tel'. The set of vCard type parameters which may be set on this field. If this list is empty and the Contact_Info_Field_Flag_Parameters_Exact flag is not set, any vCard type parameters may be used. Flags describing the behaviour of this field. Maximum number of instances of this field which may be set. MAXUINT32 is used to indicate that there is no limit.

A list of field specifications describing the kinds of fields which may be passed to SetContactInfo. The empty list indicates that arbitrary vCard fields are permitted. This property SHOULD be the empty list, and be ignored by clients, if ContactInfoFlags does not contain the Can_Set flag.

For example, a protocol in which arbitrary vCards were stored as-is would set this property to the empty list. A protocol whose notion of contact information is one each of personal phone number, mobile phone number, location, email address and date of birth, with no attributes allowed on each piece of information, would set this property to (in Python-like syntax):

[
  ('tel', ['type=home'], Parameters_Exact, 1),
  ('tel', ['type=cell'], Parameters_Exact, 1),
  ('adr', [], Parameters_Exact, 1),
  ('bday', [], Parameters_Exact, 1),
  ('email', ['type=internet'], Parameters_Exact, 1),
]

A protocol which allows users to specify up to four phone numbers, which may be labelled as personal and/or mobile, would set this property to [ ('tel', ['type=home', 'type=cell'], 0, 4), ].

Studying existing IM protocols shows that in practice protocols allow either a very restricted set of fields (such as MSN, which seems to correspond roughly to the largest example above), or something mapping 1:1 to a large subset of vCard (such as XMPP's XEP-0054).

This property MAY change, without change notification, at any time before the connection moves to status Connection_Status_Connected. It MUST NOT change after that point.

Some XMPP servers, like Google Talk, only allow a small subset of the "vcard-temp" protocol. Whether the user's server is one of these cannot be detected until quite late in the connection process.

Flags describing the behaviour of a vCard field.

If present, exactly the parameters indicated must be set on this field; in the case of an empty list of parameters, this implies that parameters may not be used.

If absent, and the list of allowed parameters is non-empty, any (possibly empty) subset of that list may be used.

If absent, and the list of allowed parameters is empty, any parameters may be used.

Indicates that this field will be overwritten when the user's alias is changed with SetAliases or when the Account's Nickname is updated. Clients that allow the editing of the Alias and the ContactInfo in the same location should hide fields with this flag.

If a client allowed the user to edit both the nickname and the ContactInfo field at the same time, the user could set them to two different values even though they map to the same property. This would result in surprising behavior where the second value would win over the first.

In addition to hiding this field when editing ContactInfo together with the user's nickname, it is recommended that clients call SetContactInfo before setting the user's nickname.

This ensures that if the user changes the nickname, the correct value will get set even if the stale nickname is mistakenly sent along with SetContactInfo.

If used, this flag typically appears on either the 'nickname' or 'fn' field.

An interface for requesting information about a contact on a given connection. Information is represented as a list of Contact_Info_Fields forming a structured representation of a vCard (as defined by RFC 2426), using field names and semantics defined therein.

On some protocols, information about your contacts is pushed to you, with change notification; on others, like XMPP, the client must explicitly request the avatar, and has no way to tell whether it has changed without retrieving it in its entirety. This distinction is exposed by ContactInfoFlags containing the Push flag.

On protocols with the Push flag set, UIs can connect to ContactInfoChanged, call GetContactInfo once at login for the set of contacts they are interested in, and then be sure they will receive the latest contact info. On protocols like XMPP, clients can do the same, but will receive (at most) opportunistic updates if the info is retrieved for other reasons. Clients may call RequestContactInfo or RefreshContactInfo to force a contact's info to be updated, but MUST NOT do so unless this is either in response to direct user action, or to refresh their own cache after a number of days.

We don't want clients to accidentally cause a ridiculous amount of network traffic.

The same value that would be returned by GetContactInfo for this contact. Omitted from the result if the contact's info is not known.