Re: [Simple] Presence data model: devices

[Alex Audu <alex.audu at alcatel.com>]

I guess one thing to think about is "can a service map to multiple devices?"

I think it certainly can.  We have seen how telephony service has grown from

being supported on only the black phone, to now being supported on a
multitude
of newer, more versatile devices.  It is not uncommon for Joe to ask a
friend
"can you call me back on my land-line phone? I can't hear you very well on
this
cell phone".

Modes of communication vary. They can include audio/visual (send audio and
receive
video after appropriate translations, send audio and receive audio, send
video and
receive audio, send video and receive video), sensory, and tactile
communication modes.
It is possible but rare that one device can support all these modes;
however it most likely
that the various modes will be supported on different devices optimized for
each mode.
So, I am not sure if we can  dimish the importance of device addressability.

Regards,
Alex.

Henning Schulzrinne wrote:

> Let me try to formulate my concerns about devices somewhat less
> flippantly than in my earlier rush mail. I'm probably missing pieces,
> but we need to start somewhere. A fair treatment would probably require
> another draft...
>
> I have the following concerns:
>
> (1) Devices in the data model draft don't correspond exactly to the
> physical model that naive users have of a device. The data model states,
> for example, that
>
>     ... it is perfectly
>     acceptable to use this model to talk about that PC as being composed
>     of two separate devices.
>
> There does not appear to be any clear-cut rule that would allow a
> presentity or watcher to decide whether a single physical device
> consists of one or more logical or virtual devices. Personal-area
> network devices such as assemblies of BlueTooth gadgets pose similar
> problems, as both a view as a single device or as individual devices are
> reasonable. Locally, we have created virtual multimedia devices that
> consist of multiple pieces of plastic (a projector, a speakerphone, an
> IP array microphone). They act exactly like one multimedia device in
> most senses.
>
> (2) Devices have ill-defined properties that are implied, but not
> stated, to the watcher.
>
> The only architectural motivational paragraph that I could find is in
> Section 4: "Furthermore, the concept of device adds the ability to
> correlate services together.  The device models the underlying platform
> that supports all of the services on the phone.  Its state therefore
> impacts all services."
>
> However, the types of states that are shared are implicit, not explicit.
> Clearly, devices do not share *all* states across services. For every
> possible state, there are plausible exceptions where services on the
> device do *not* share that state. I gave a few examples, but the burden
> is on the device proponent to prove that the watcher can unambiguously
> determine which states are indeed shared and why such knowledge is
> useful to the watcher. The likely case is that some states for some
> services are shared for some devices, while others are not.  (I'm
> guessing that any reasonable device will have one shared location state,
> at least at GPS resolution, but the example above shows that you can
> violate even that assumption with a bit of forward thinking.)
>
> I agree that state inference models are useful - the draft alludes to
> that. However, many of these are probably best expressed as either local
> rules at the composer, based on local knowledge available to the
> composer, or as heuristics ("if my two mobile devices report two
> different locations, pick my Brand X cell phone since I carry that to
> job sites"; "if my cell phone service is reporting me as talking, mark
> presentity status as busy"). It is unclear how a watcher would benefit
> from such decontextualized knowledge.
>
> (3) Some of the motivating assumptions are short-term or debatable.
>
>     For many users, devices represent the ability
>     to communicate, not services.  Frequently, users my statements like,
>     "call me on my cell phone" ...
>
> It is debatable that users actually want to refer to a device, even
> though the current service=device abstraction encourages that. As soon
> as a service is available on multiple devices, users are just as likely
> to say "call me on my 3G service". Since a device in this model is not
> reachable itself (it only has a URN that does not resolve), this device
> notion can't actually be implemented by a user - the device tuple cannot
> be used to actually call the device. Thus, there is no functionality
> gain and the user still has to use a service tuple, with caller prefs or
> an explicitly labeled service, to do anything of use. If you want to
> call the Nokia-made blue cell phone of mine, there has to be a service
> tuple, with URI, that maps one-to-one to that device. If a service maps
> to multiple devices, I can't actually call that one piece of plastic.
>
> My proposal is simple: remove the notion of devices from the data model.
> If there is a need to allow one-to-many references (e.g., one service
> found at multiple locations due to uncertainties in where the presentity
> is), we should have appropriate means to express this by value or by
> reference for that particular service tuple and property.
>
> I would like to see examples of services that significantly benefit from
> adding devices and that cannot be similarly expressed by the
> summarization model across service instances. (= a property that is
> shared by all instances of a service or there there is at least one
> instance that can be selected is shown.)
>
> My basic contention is simplicity: we should have a minimalist data
> model that cannot be reduced any further.
>
> Henning
>
> _______________________________________________
> Simple mailing list
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple