1 / 13

OMA-DS-DS_DO-2007-0002-INP_vCard_Workshop OMA DS and VCard

OMA-DS-DS_DO-2007-0002-INP_vCard_Workshop OMA DS and VCard. Submitted To: OMA DS for presentation at vCard workshop (hosted by the Calendaring and Scheduling Consortium) Date: 18 Sep 2007 Availability: Public Contact: Mark Paterson, mark.paterson@oracle.com

kishi
Télécharger la présentation

OMA-DS-DS_DO-2007-0002-INP_vCard_Workshop OMA DS and VCard

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OMA-DS-DS_DO-2007-0002-INP_vCard_WorkshopOMA DS and VCard Submitted To: OMA DS for presentation at vCard workshop (hosted by the Calendaring and Scheduling Consortium) Date: 18 Sep 2007 Availability: Public Contact: Mark Paterson, mark.paterson@oracle.com Darryl Champagne, dgc@funambol.com Source: OMA DS Working Group USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT. THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS. Intellectual Property Rights Members and their Affiliates (collectively, "Members") agree to use their reasonable endeavours to inform timely the Open Mobile Alliance of Essential IPR as they become aware that the Essential IPR is related to the prepared or published Specification. This obligation does not imply an obligation on Members to conduct IPR searches. This duty is contained in the Open Mobile Alliance application form to which each Member's attention is drawn. Members shall submit to the General Manager of Operations of OMA the IPR Statement and the IPR Licensing Declaration. These forms are available from OMA or online at the OMA website at www.openmobilealliance.org.

  2. What is OMA DS? OMA DS (formerly known as SyncML) is most commonly thought of as a method to synchronize contact and calendar information between some type of handheld device and a computer. The new version of the specification includes support for email providing a standard protocol alternative to proprietary solutions.

  3. How does OMA DS relate to vCard? In order to synchronize contact information the OMA Enabler Specifications specify that vCard 2.1 or 3.0 be used as the data object format for the contact information

  4. What problems have been seen? Since Contact Synchronization uses vCard, problems with the underlying data object format effect the quality of the sync. • Too Many Type combination possibilities. • No good way of knowing what a device can store or provide. • No support for enumerating contact methods. • Proper format for date time stamps not sufficiently defined. • Proper format for phone numbers not sufficiently defined. • Proper format for addresses not sufficiently defined. • Obsolete methods of communication supported while new methods are not.

  5. Problem #1Too Many Type combination possibilities TEL;TYPE=VOICE,CELL TEL;TYPE=CELL,VOICE TEL;TYPE=CELL These are all perfectly legal!!! You can probably specify your home cell submarine phone number  So why is this an issue? • Some devices will only accept certain combinations • Some devices will accept a combination but send it back differently What would be nice to see? • A more stringent definition of acceptable combinations. • An enforcement regarding what should be supported.

  6. Problem #2No good way of knowing what a device can store or provide Server sends the following to a device… TEL;type=WORK:+1 (617) 555-1234 TEL;type=HOME:+1 (617) 555-1235 TEL;type=SUBMARINE:+1 (617) 555-1236 Device sends back the following on a later sync… TEL;type=WORK:+1 (617) 555-1234 TEL;type=HOME:+1 (617) 555-1236 What happened? • Device doesn’t support submarine numbers (go figure ) and ignored it? • User deleted the submarine number? What would be nice to see? • Better way of understanding what a device accepts. • An enforcement regarding what should be supported.

  7. Problem #3No support for enumerating contact methods Server sends the following to a device… TEL;type=WORK:+1 (617) 555-1234 TEL;type=WORK:+1 (617) 555-1235 TEL;type=WORK:+1 (617) 555-1236 Device sends back the following on a later sync… TEL;type=WORK:+1 (617) 555-1234 TEL;type=WORK:+1 (617) 555-1236 What happened? • Device only supports 2 work numbers and ignored the 3rd one? • User deleted one of the numbers? Which one? What would be nice to see? • Some way of enumerating or uniquely identified a contact method • Could be across all methods or for methods of the same type.

  8. Problem #4Proper format for date time stamps not sufficiently defined The format of BDAY must be defined more strongly in order to have always the same format sent or received. This unique format could be the following (which includes time in UTC form) : yyyymmddThhmmss{sign}thtm (ISO 8601 basic format only) • ·where all values yyyy, mm, ss, hh, mm, ss, th, tm are mandatory (even if null or unknown (default 00 )). • ·where T is mandatory • ·where {sign} (e.g. "+" or "-") is mandatory • ·where Z is forbidden (in ISO 8601, after the time value Z indicates UTC time) • ·where hyphens ("-") are forbidden in date value • ·where colons (":") are forbidden in time and UTC offset values (thtm)

  9. Problem #5Proper format for phone numbers not sufficiently defined 13336669999 +13336669999 1 (333) 666-999 All of these are valid. Some servers store the country code, area code, and actual number separately. Some devices want to display them a certain way. So why is this an issue? • Formatting preferences on either end affect the other. Country code end up as area codes, etc… • Can’t use them to make a phone call some times!!! What would be nice to see? • A stringent definition of how phone numbers should be defined.

  10. Problem #6Proper format for addresses not sufficiently defined …See problems #4 and #5 • Label property seems obsolete but used by some to avoid supporting ADDR property.

  11. Problem #7Obsolete methods of communication supported while new methods are not BBS, MODEM, PCS, CAR, ISDN (SUBMARINE isn’t actually in there  ) AOL, AppleLink, ATTMail, CIS, eWorld, IBMMail, MCIMail, POWERSHARE, PRODIGY, TLX How do you specify how to reach someone using IM?

  12. What would help OMA DS? • A Vcard 3.0 that solved these issues (calsify for vCard). • Test Suites that help ensure better conformance and interoperability. Some attempts done within OMA to help but largely ignored… vObject Minimum Interoperability Profile http://www.openmobilealliance.org/release_program/docs/vObject/v1_0-20050118-C/OMA-TS-vObjectOMAProfile-V1_0-20050118-C.pdf A new contact format might be interesting but overall,despite its inadequacies, vCard has been a success, it is supported all over the place.

  13. Conclusion Specify it and we will use it.

More Related