Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53

From: "Adrian Bateman" <[email-masked]>
Date: Wed, 1 May 2002 12:37:38 +0100

On 06 April 2002 00:11, Paul Kyzivat wrote:
> Callerprefs provide a number of dimensions on which to classify a 
> contact (tuple). These could be mapped directly to status values. Or 
> they could be mapped to some new elements within a tuple. They are a 
> bit more complex than the what is currently defined by 
> urn:ietf:params:cpim-presence:status-type:basic. There are a number of

> preference parameter types (class, duplex, feature, language, media, 
> mobility, methods, priority), and each in turn has an enumerated set 
> of possible values. (There is also a "description" parameter, but it 
> probably should be mapped to <note>, and a q-value that is already 
> represented as the priority attribute of <contact>.)

A new draft describing IMPP PIDF has been posted and should show up
shortly. It includes changes from recent IMPP discussions but still
leaves a few issues outstanding.

One question I have with reference to the text above is regarding the
priority attribute of <contact>. In the current draft, the priority is
defined in the range 0 to 255. The description above suggests mapping a
q-value to the priority. What range does this have? Do you feel the
priority as currently defined is appropriate or are there any
alternative suggestions?

Best regards,

Adrian.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 May 2002 15:24:59 -0400

> priority as currently defined is appropriate or are there any

Hmm - good question. I had not looked very closely at the schema, and hadn't noticed that the priority range was 0-255. In callerprefs, the q-value is a real number in the
range [0.0-1.0]. The good and the bad of that is that the precision isn't defined, so you potentially have an infinite number of values, but don't know how many will
actually be supported.

Of course it is possible to map between the two ranges, though problems of roundoff may occur.

The mapping would be best if both standards agreed on the same range. The q-value definition is inherited by SIP (from HTTP?) so would be difficult to change. Is it
possible to change this to match in PIDF? If not, maybe something new is needed for the q-value to map to. (But it would be ugly to have two priority values, without a
clear reason for each.)

	Paul