SMG4/TSG-CN3/TSG-T2
London, 15-19 March 1999	TSGT2#2(99)079

Agenda Item:	Pre-WAP Forum Meeting preparation

Source:	Nokia

Title:	Discussion paper: Harmonisation of MExE capability and preference information tokens with WAP Uaprof

Document for:	

___________________________________________________________________________

We are defining tokens for indicating capability and preference information, and simultaneously the WAP forum has a group called Uaprof for similar purposes, and W3C has defined a CC/PP (Composite Capability/Preference Profiles) exchange protocol.

In order to avoid parallel standardisation efforts, we should make sure we are not reinventing the wheel or creating incompatible specifications. Since the WAP Uaprof -group has adopted CC/PP with the focus to map the CCPP Exchange Protocol over WAP, the MExE group should aim at harmonising the MExE capability indication methods with WAP Uaprof results.

See the following documents for more information about W3C work on CC/PP:
http://www.w3.org/TR/1998/NOTE-CCPP-19981130/
http://www.w3.org/TR/NOTE-CCPPexchange

We can be confident that the Uaprof group will be in tune with W3C CC/PP. I advise all those who have access to the Uaprof documents to see if there are key individuals representating both these efforts.

Our approach should be to identify the MExE capability negotiation tokens which are urgently required for R98, and send a liaison statement to WAP forum asking for their advice on naming conventions, syntax etc. We should list the tokens we need for R98. (The reason for choosing a subset of the tokens for R98 is that we are asking their quick advice and assistance, in which case we should keep it simple.)

They probably won't be able to standardise these tokens quickly enough for us, but we should at least get some commitment from them that if we follow certain general guidelines, then our tokens will not conflict with theirs when they do finalise their tokens.

This will result in a "bare bones" set of tokens we can standardise for R98 and a wish list for R99 (which will eventually be in tune with the WAP forum.)

Tokens we need for R98, but which even I have comments about (let alone WAP Uaprof):
MExE-class:
More generic form could be "Conformance", e.g. "Conformance: MExE CM2" or... "Conformance: WAP 1.1"

MExE-Spec:
Not really required at all. E.g. redundant by "Conformance: MExE 1.5.0 CM2"

MExE-manuf:
Could be more generic, like "Device", e.g. "Device: Nokia 9110"

MExE-model:
Redundant if using "Device" as above...

MExE-uprofile: (User profile)
What is this really?

Other tokens we need for R98:
MExE-srvcs: (Identification on where information on the PLMN-provided MExE services may be found)
MExE-kbdlg: (Keyboard human language)
MExE-hlang: (Human Language
MExE-pntr: (Pointing device)
MExE-res: (Display)
MExE-URL: (An indirect reference to a location where the MExE MS's characteristics may be obtained)

Non urgent things which could be moved out of the spec and into an
appendix until Uaprof standardises them. i.e. delayed to R99:
MExE-SN: (Serial Number) Hardware Version would be more appropriate.
MExE-SV: (Software Version)
MExE-chars: (Characters)        
MExE-clrs: (Colour/monochrome)
MExE-grey: (Greyscale)
MExE-voice: (Input mode)
MExE-kbdid: (Keyboard type)
MExE-keys: (Number of keys)
MExE-flang: (Formal Language)
MExE-adprt: (Additional Protocols)
MExE-bear: (Supported Bearers)
MExE-cldif: (Difference to base Classmark)
MExE-memty: (User authorised available memory)
MExE-mem: (Amount of memory)
MExE-audio: (Audio codec type)
MExE-video: (Video codec type)
MExE-tsize: (Transfer limits)
MExE-ttime: (Transfer Time)
MExE-loc: (Location Information type)
MExE-locin: (Actual location information as defined by type)
MExE-addch: (Additional characteristics)
MExE-addin: (Additional Information)