Hi, *1. In MDM context, we have 3 kinds of Token* Token, MagicToken and UnlockToken
Token,MagicToken is used for push notification from MDM Server to APNS server Unlock Token is used for ClearPasscode DM-Command - to Clear the Passcode for a Device The size of this token is little bit large. It's server to device payload. *2. App Push Notification (Client Agent) we have 1 Token* This token is used to send App Push Notification from MDM server to APNS Used for Alert Message and Location Identification. >From the iOS MDM point of view, we have 4 Tokens 1. Tokens which are used for sending MDM Push Notification 2. Tokens which are used for sending App Push Notification but DM-Command Specific 3. Token for DM-Command specific (ClearPasscode) for a device. In [1] we have this for every push message to the APNS server from MDM for each device . [2] we have to use this for some DM-Command specific function (Alert, Location) [3] we have to use this for some DM-Command specific function (ClearPasscode) - is not used quite often. Differences between [2] and [3] [2] uses MDM Push Notification [3] use APNS Push Notification If we look at the 3 platforms (iOS,Android,Windows) , all 3 uses push notification. But the number of tokens and the way its used is little bit different. We can have a field called PUSH_TOKENS which is now device independent and store the tokens as a JSON string , so each platform can identify their respective tokens. In iOS we have DM-Command specific token which is not used for push messages. This can be stored in a extra field OTHER-INFO. but it has to be key-value pair since there can be other fields. Thanks, Shan On Mon, Feb 16, 2015 at 12:17 PM, Harshan Liyanage <hars...@wso2.com> wrote: > Hi Dilshan, > > Currently the device table in mobile database has following fields. > > - MOBILE_DEVICE_ID > - REG_ID > - IMEI > - IMSI > - OS_VERSION > - DEVICE_MODEL > - VENDOR > > When considering iOS platform I think that we can map all other iOS fields > to above fields except for the magic-token & unlock-token. We can map the > push-token to REG_ID field & IMO I think that we can change the column name > to "*PUSH_TOKEN*" since it is more generic term than "*REG_ID*" . For > other two tokens we can use a separate field (if we are storing 2 tokens as > a json string if those records are not frequently accessed) or 2 separate > columns. In android-platform we have used WIFI Mac address as the > MOBILE_DEVICE_ID. > In your case I guess we'll need a separate column for storing mac address > too. > > Since all other device information (device-capacity, bluetooth mac etc) > will be available for all mobile platforms we'll need a generic way to > handle these. I suggest to have a separate field in our device-table like " > *OTHER_INFO*" and store all of these other as a json string as those > information will be accessed as a whole. > > @Asok : Could you please share the list of fields available in Windows > platform? > > Thanks, > > Lakshitha Harshan > Software Engineer > Mobile: *+94724423048* > Email: hars...@wso2.com > Blog : http://harshanliyanage.blogspot.com/ > *WSO2, Inc. :** wso2.com <http://wso2.com/>* > lean.enterprise.middleware. > > On Mon, Feb 16, 2015 at 11:42 AM, Dilshan Edirisuriya <dils...@wso2.com> > wrote: > >> Hi, >> >> Following are the additional fields found in iOS MDM other than the once >> we find in Android. Since our table structure is little bit tight to >> Android platform it is necessary to identify the extension points to store >> these fields as well along with Windows fields. >> >> 1) Challenge - since iOS get above information in 2 steps it has a >> challenge password embedded in the iOS payload. This is to verify the >> identify of the device together with its UDID. >> >> 2) Product - for this I will be sending this as either iPhone, iPad or >> iPod by looking at sub-strings. >> >> 3) Serial - serial number of the device. >> >> 4) Version - iOS device type. >> >> 5) IMEI - IMEI number. Incase there is no IMEI number it will return >> empty (ie iPad without the sim). >> >> 6) Model - model number of the device. >> >> 7) UDID - mapping to device identifier. >> >> 8) Token, Magic token and unlock token for normal push and MDM push >> notifications. >> >> After the enrollment using device information command we can fetch the >> device information such as AvailableDeviceCapacity, BluetoothMAC, >> BuildVersion, CarrierSettingsVersion, CurrentCarrierNetwork, CurrentMCC, >> CurrentMNC, DataRoamingEnabled, DeviceCapacity, DeviceName, ICCID, IMEI, >> IsRoaming, Model, ModelName, ModemFirmwareVersion, OSVersion, PhoneNumber, >> Product, ProductName, SIMCarrierNetwork, SIMMCC, SIMMNC, SerialNumber, UDID >> and WiFiMAC. >> >> Please note that these fields could vary based on the OS version of the >> device. >> >> We need to make these fields generic which will be helpful for the MDM to >> fetch data accurately in generic manner as well as store them generically >> so that any platform can fit into the existing architecture. >> >> >> Regards, >> >> Dilshan >> >> -- >> Dilshan Edirisuriya >> Senior Software Engineer - WSO2 >> Mob: + 94 777878905 >> http://wso2.com/ >> https://www.linkedin.com/profile/view?id=50486426 >> > > -- *Shanmugarajah (Shan)* Director, Mobile Architecture, WSO2, Inc.; http://wso2.com Email: s...@wso2.com Mobile : +94777748260 Blog: http://shanfour.blogspot.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
