[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] Updated RPID
Henning Schulzrinne wrote:
My concern is that losing source information is not desirable, as it
makes it rather difficult for any downstream entity to decide which
information might be more credible.
We discussed this extensively on the design team.
It was concluded that we could support the reporting of conflicting
information downstream, in later extensions, by inclusion of multipel
values for a particular element along with its source. That meant that
the baseline mode of operation was kept simple. Given the confusion
we've had all along about interpretation of data in multiple places, the
tradeoff seemed appropriate.
I, for one, strongly support this decision. I think, prior to the model,
we were on a path to failure. We clearly had a lack of agreement or
understanding on what these attributes meant and what they were saying.
No small part of that was that any data could appear anywhere. I am
reluctant to return to that. I think that consistent and coherent
information should be the baseline mode of operation, with conflicting
data and source information being an extension, something we can do later.
To be concise, Dan wrote:
So in the presence model draft, the cell phone service would report
that you are driving using the <person> tuple, and the PDA would
report that you are in a meeting also using the <person> tuple.
This would be the case because the information applies to the person
(although it is reported by various services). It is then up to the
composition policy to decide which information should be displayed.
It could merge the information so that potentially conflicting
information is displayed to the watcher if that is the composition
policy in use.
Correct up to the last sentence - as above, we are not supporting, in
this current version, the ability to indicate conflicting data.
To answer Paul's original question, he wrote:
I have a question about how the data model xml type extensions for
<person> and <device> interact with the status and characteristic
types defined in various places.
(This may just be a matter of my ignorance of XML details.)
The data model defines a number of abstract types. I infer that the
only elements that are permitted as capabilities or status of person
or device must have themselves been declared as extensions to the
corresponding abstract type.
If that is true, then it would seem to rule out the same type being
used in more than one of <tuple>, <person>, or <device>. This would
minimally mean that every type defined in RPID will need to be
revised to specify which container it is intended for.
This also means that we can't have types that are intended to be
useful in more than one of these. (E.g. idle.)
If you want an element to be valid for both person and device, than yes,
you would need to define it twice. You can give it the same name, and
just use different namespaces.
I think that being crisp about its interpretation in each of the
different components of the data model is a feature of this approach,
not a bug. You need to EXPLICITLY make it apply to all three, rather
than have that be the case only unless you say otherwise.
In the case of rpid, based on my pass through the -04 version, there was
only one attribute that was plausibly valid in two places - idle, for
either device or service. We've in fact been debating its validity for
service in any case.
Thus, the fact that this is a problem in theory and not in practice,
says to me that we are doing the right thing.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Chief Technology Officer Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple