thesimplepresenceandeventarchitecture(編輯修改稿)
2025-08-13 17:38 本頁面
【文章內(nèi)容簡介】 esolve contradictions PUBLISH Presence data architecture candidate presence document watcher filter raw presence document postprocessing position (merging) final presence document difference to previous notification SUBSCRIBE NOTIFY remove data not of interest watcher Presence data model “calendar” “cell” “manual” audio, video, text video person (presentity) (views) services devices Rich presence ? Rich presence = more information than open/closed ? automatically derived from – sensors: physical presence, movement – electronic activity: calendars ? Rich information: – multiple contacts per presentity ? device (cell, PDA, phone, …) ? service (“audio”) – activities, current and planned – surroundings (noise, privacy, vehicle, …) – contact information – posing (typing, recording audio/video IM, …) RPID = rich presence ? Provide watchers with better information about the what, where, how of presentities ? facilitate appropriate munications: – “wait until end of meeting” – “use text messaging instead of phone call” – “make quick call before flight takes off” ? designed to be derivable from calendar information – or provided by sensors in the environment ? allow filtering by “sphere” – the parts of our life – don’t show recreation details to colleagues RPID: rich presence person tuple device activities class mood placeis placetype privacy relationship serviceclass sphere statusicon timeoffset userinput Presence and privacy ? All presence data, particularly location, is highly sensitive ? Basic location object (PIDFLO) describes – distribution (binary) – retention duration ? Policy rules for more detailed access control – who can subscribe to my presence – who can see what when tuple id=sg89ae status gp:geopriv gp:locationinfo gml:location gml:Point gml:id=point1“ srsName=epsg:4326
黨政相關相關推薦
鄂ICP備17016276號-1