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

> Hmm - good question. I had not looked very closely at the 
> schema, and hadn't noticed that the priority range was 0-255. 

It's defined as that range in "4.1.5. The <contact> element" ... "The value
of the
   attribute MUST be an integer ranged from 0 to 255."  I put it in the
schema to mirror that.

xml schema datatypes has IEEE floats and doubles and can set ranges.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email protected]]
> Sent: Wednesday, May 01, 2002 12:25 PM
> To: [email protected]
> Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'; 'Robert Sparks';
> [email protected]; [email protected]
> Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> 
> 
> Adrian Bateman wrote:
> > 
> > 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?
> 
> 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
> 
> 
> 
>   [reminder: [email protected] for non-technical 
> discussions, please]
> 


  [reminder: [email protected] for non-technical discussions, please]