1、 ETSI TR 102 334 V1.1.1 (2004-05)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);vCard and vCalendar on fixed network for PSTN/ISDNETSI ETSI TR 102 334 V1.1.1 (2004-05) 2 Reference DTR/TISPAN-01012-FMMS Keywords SMS, PSTN, ISDN ETSI 6
2、50 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be down
3、loaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the referenc
4、e shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is
5、available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editoretsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in
6、all media. European Telecommunications Standards Institute 2004. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPT
7、M is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 102 334 V1.1.1 (2004-05) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 3 Definitions and abbreviations.5 3.1 Definitions5 3.2 Abbreviations .5 4 vC
8、ard 6 4.1 Description .6 4.2 Mandatory properties .6 4.2.1 Version VERSION.7 4.2.2 Name N.7 4.3 Strictly recommended properties7 4.3.1 Telephone Number TEL 7 4.4 Optional properties.7 4.4.1 Electronic Mail EMAIL.7 4.4.2 Categories X-CATEGORIES8 4.4.3 Class X-CLASS8 4.4.4 Last Revision REV.9 4.5 Exam
9、ple for a minimal contact exchange.9 5 vCalendar .9 History 10 ETSI ETSI TR 102 334 V1.1.1 (2004-05) 4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly
10、available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
11、server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or ma
12、y be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). ETSI ETSI TR 102 334 V1.1.1 (2004-05) 5 1 Scope The present doc
13、ument provides some recommendations for implementation of vCard and vCalendar in fixed networks. 2 References For the purposes of this Technical Report the following references apply: 1 “vCard - The Electronic Business Card“ The Internet Mail Consortium (IMC) version 2.1 - September 18th, 1996 (URL:
14、http:/www.imc.org/pdi/vcard-21.doc). 2 IETF RFC 2425 (Version 3): “MIME Content-Type for Directory Information“. 3 IETF RFC 2426 (Version 3): “vCard MIME Directory Profile“. 4 IETF RFC 2445: “Internet Calendaring and Scheduling Core Object Specification (iCalendar)“. 5 IETF RFC 2446: “iCalendar Tran
15、sport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries“. 6 IETF RFC 2447: “iCalendar Message-Based Interoperability Protocol (iMIP)“. 7 ETSI TS 123 040: “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications Sys
16、tem (UMTS); Technical realization of Short Message Service (SMS) (3GPP TS 23.040)“. 8 ETSI ES 201 986 (V1.1.2): “Services and Protocols for Advanced Networks (SPAN); Short Message Service (SMS) for PSTN/ISDN; Service description“. 9 ETSI ES 201 912: “Access and Terminals (AT); Short Message Service
17、(SMS) for PSTN/ISDN; Short Message Communication between a fixed network Short Message Terminal Equipment and a Short Message Service Centre“. NOTE: vCard and vCalendar are trademarks of the Internet Mail Consortium. vCard and vCalendar documents are available on http:/www.imc.org/pdi/. 10 ISO 8601:
18、 “Data elements and interchange formats - Information interchange - Representation of dates and times“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: vCard: electronic business card vCalendar: cross-platform sched
19、uling 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: EMS Enhanced Messaging Service IMC Internet Mail Consortium (http:/www.imc.org/) ISDN Integrated Services Digital Network ETSI ETSI TR 102 334 V1.1.1 (2004-05) 6 PSTN Public Switched Telephone Networ
20、k SMS Short Message Service 4 vCard 4.1 Description vCard should be used by PSTN/ISDN terminals to exchange personal information (as contact card). This exchange can be made between two terminals or between a terminal and a server. vCard uses EMS as transport mechanism according to ES 201 912) 9 (SM
21、S for PSTN/ISDN and TS 123 040 7 (3GPP; Technical realization of SMS; Release 5). A contact exchange may need a concatenated EMS, i.e. more than one SMS segment is transmitted. If a terminal supporting vCard exchange is not supporting concatenation, it should be able to receive and read at least the
22、 vCard information contained in the first segment. Terminals supporting vCard exchange shall be compliant to vCard version 2.1 as defined in document 1: Emitting an EMS containing a vCard object, PSTN/ISDN terminals or servers supporting vCard exchange shall use vCard version 2.1, with the following
23、 supplementary recommendations: - The mandatory properties which are defining a contact in a vCard exchange are Version VERSION and Name N. - The Telephone Number TEL property is strictly recommended to be used, since it is seen as an essential property for vCard exchange. - As addressed terminals m
24、ay not support concatenation, it is recommended to put essential information of a contact in the first segment. Therefore, the order of the mandatory properties should be Version VERSION, Telephone Number TEL and Name N. - Additional properties should be other Telephone Number TEL values, Last Revis
25、ion REV, Electronic Mail EMAIL, Categories X-CATEGORIES and Class X-CLASS which are defined below. Receiving an EMS containing a vCard object, terminals or servers supporting vCard exchange should meet the following recommendations: - According to 7, 8 and 9, if a terminal is not supporting concaten
26、ated messages, it will receive and read independently each segment. In this case, terminals should extract from the first segment of the concatenated messages the main properties of the received contact. The main properties are Version VERSION, Telephone Number TEL and Name N. - The following additi
27、onal properties should be read: other Telephone Number TEL values, Electronic Mail EMAIL, Categories X-CATEGORIES, Class X-CLASS and Last Revision REV which are defined below. 4.2 Mandatory properties The Version VERSION and Name N properties are mandatory for devices compliant to vCard version 2.1.
28、 The following information should be the minimum handled by terminals supporting vCard exchange (can be completed by other types). ETSI ETSI TR 102 334 V1.1.1 (2004-05) 7 4.2.1 Version VERSION To specify the version of the vCard specification used to format this vCard. This property is mandatory for
29、 vCard writers conforming to the specification of vCard version 2.1 1. Terminals supporting vCard exchange shall support the property Version VERSION. EXAMPLE: VERSION:2.1 4.2.2 Name N To specify the components of the name of the object the vCard represents. This property is mandatory for vCard writ
30、ers conforming to the specification of vCard version 2.1 1. The property value consists of the components of the name specified as positional fields separated by the Field Delimiter character (ASCII decimal 59). The property value is a concatenation of the Family Name (first field), Given Name (seco
31、nd field), Additional Names (third field), Name Prefix (fourth field) and Name Suffix (fifth field). Terminals supporting vCard exchange shall support the property Name N. EXAMPLE: N:Dawson;Franck 4.3 Strictly recommended properties 4.3.1 Telephone Number TEL This property specifies the Telephone Nu
32、mber for telephony communication with the object the vCard represents. Support for this property is optional for vCard writers conforming to the specification of vCard version 2.1 1. In addition to the vCard version 2.1 specification of this property, the following recommendations are given for vCar
33、d exchange in fixed networks for PSTN/ISDN: The property Telephone Number TEL should be supported by terminals implementing vCard exchange. The supported length of the canonical number string used for the telephone number should be at least 20 characters. In case the terminal supports TEL types, the
34、 following values should be supported for the Telephone Type: - HOME; - WORK; and - CELL. This means that such PSTN/ISDN terminals or servers supporting vCard exchange should be able to send, to receive and to store a contact with at least one of these values for the Telephone Type. EXAMPLE: Receivi
35、ng TEL;HOME:0123456789, the information should be stored in the corresponding structure. 4.4 Optional properties 4.4.1 Electronic Mail EMAIL This property specifies the address for electronic mail communication with the vCard object. Support for this property is optional for vCard writers conforming
36、 to the specification of vCard version 2.1 1. ETSI ETSI TR 102 334 V1.1.1 (2004-05) 8 Terminals supporting vCard exchange and additionally the sending of SMS messages to email addresses may support the property EMAIL (Electronic Mail). The supported length for the electronic mail address should be a
37、t least 50 characters. EXAMPLE: EMAIL;INTERNET: 4.4.2 Categories X-CATEGORIES To specify application category information about the vCard. The Categories property may be used to form groups of contacts to make easier management and consultation of the terminals phonebook or of the network contact bo
38、ok. As far as possible, a same contact may not be duplicated in two different categories. Groups may be FAMILY, FRIENDS, WORK and SERVICE. This last category may be used to store specific services numbers such as school, garage, doctor, etc. Special services or functionalities may be associated to a
39、 category (messaging, call forward, ringing tone, etc.). The Categories property does not exist in the specification of vCard version 2.1 1. The Categories property may be implemented in a vCard version 2.1 object by using the EXTENSION property. Conforming to the vCard version 2.1 specification of
40、the EXTENSION properties, the initial sub-string X- of the EXTENSION property shall be followed by the property parameter name CATEGORIES. The Categories X-CATEGORIES property is optional for terminals supporting vCard exchange. When implemented, the values supported for the Categories X-CATEGORIES
41、property should be at least: FAMILY, FRIENDS, WORK and SERVICE. If other values are received but not supported by the terminal, a default value for the Categories X-CATEGORIES property may be used to store the information (e.g. NO CATEGORY). To ease user approach and avoid multiple definition of the
42、 same phonebook directory, some restrictions will apply to the value for this property: The value for X-CATEGORIES should consist of only one word. It should always be written in uppercase, accentuated characters should be converted to their non accentuated equivalent. While received, the value for
43、X-CATEGORIES should be converted to uppercase without accentuated characters before storage. EXAMPLE: X-CATEGORIES:FAMILY 4.4.3 Class X-CLASS To specify the access classification for a vCard object. The Class property may be used to define different levels of access for management and consultation o
44、f contacts in the terminals phonebook or in the network contact book. Contacts with Class propertys value equal to PUBLIC are accessible to any user of the phonebook. Contacts with Class propertys value equal to PRIVATE require an identification of the user to be accessible. The Class property does
45、not exist in the specification of vCard version 2.1 1. The Class property may be implemented in a vCard version 2.1 object by using the EXTENSION property. Conforming to the vCard version 2.1 specification of the EXTENSION properties, the initial sub-string X- of the EXTENSION property shall be foll
46、owed by the property parameter name CLASS. The Class X-CLASS property is optional for terminals supporting vCard exchange. When implemented, the values supported for the Class X-CLASS property should be at least: PUBLIC, PRIVATE. To ease user approach and avoid multiple definition of the same phoneb
47、ook directory, some restrictions will apply to the value for this property: The value for X-CLASS should consist of only one word. It should always be written in uppercase, accentuated characters should be converted to their non accentuated equivalent. While received, the value for X-CLASS should be
48、 converted to uppercase without accentuated characters before storage. EXAMPLE: X-CLASS:PRIVATE ETSI ETSI TR 102 334 V1.1.1 (2004-05) 9 4.4.4 Last Revision REV To specify the combination of the calendar date and time of day of the last update to the vCard object. In addition to the vCard version 2.1
49、 specification of this property, the following recommendations are given for vCard exchange in fixed networks for PSTN/ISDN: The property Last Revision REV should be supported by terminals implementing vCard exchange. The property value should be a character string conforming to the basic format of ISO 8601 10. The value should be in local time of ISO 8601. EXAMPLE: REV:19951031T222710 4.5 Example for a minimal contact exchange BEGIN:vcard VERSION:2.1 N:Dawson;Franck TEL;HOME:0123456789 END:v
