Subject: RE: [Simple] prescaps and priority (Was: I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt)

From: [email-masked]
Date: Thu, 28 Oct 2004 10:43:59 +0300

Hi,

inline

> I also see another issue that I should have caught before, because it 
> isn't new. And it is as much a problem for RFC3840 as it is a 
> problem here:
> 
> The issue is how priority is represented. As part of doing 3840, 
> priority was changed from a set of tokens (non-urgent, 
> normal, urgent, 
> emergency) to numeric values (10, 20, 30, 40) so that callerprefs 
> matching on ranges would be possible. The description says
> 
>      "A value of X means that the device is willing to
>       take requests with priority X and higher."
> 
> However no actual examples are given, and the above description is 
> slightly at odds with the way numeric values are to be handled with 
> feature params. To get as close as possible to the above, and use 
> numeric values so that callerprefs matching works, a value of normal 
> ought to be represented as:
> 
> 	priority="#>=20"
> 
> If instead it were simply represented as priority="20" then 
> the 20 would 
> simply be a token, and callerprefs range matching would not work.

yes, you are right. 
 
> The impact of this on prescaps is the value of priority should permit 
> one or more numeric ranges. (Negation is also permitted, but 
> that can be 
> mapped into a different set of ranges.)

Right, and in practice this means that we need to be able to represent comparison operators =, >=, and <= and also numeric ranges. I don't this we actually need to use # here as there should not any change to confuse this value to a token or to a string. I can think of following solutions:

1)
add a operation parameter into <priority> element. With this we would have something like
<priority op="[op]">priority</priority. op could have values =, >=, <= and range. Only ugly think with this is the range. We would need to give range for example using similar syntax as in callee caps: 4/8. This will also have an effect that priority needs to be a string type element.

2)
Use substitutiongroups as is already done in some other elements defined in prescaps. Schema would look something like (this has not been validated):
      <xs:complexType name="prioritytype">
        <xs:sequence>
           <xs:element
            ref="tns:prioritytypes"
            maxOccurs="1"/>
        </xs:sequence>
     </xs:complexType>
     <xs:element name="prioritytypes" abstract="true"/>
     <xs:element name="equals" substitutionGroup="tns:prioritytypes"/>
     <xs:element name="lessorequals" substitutionGroup="tns:priorityypes"/>
	and so on

Solution 1 would be somewhat simpler. Solution 2 would allow us to use correct types for priorities and it would be consistent with rest of the schema. So I would vote for option 2. Other solution are also welcome.
	
- Mikko 

> I expect this issue will require a bit more discussion. :-(
> 
> 	Paul
> 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Oct 2004 22:29:44 -0400

Mikko,

My xml skills are still limited, so I'm not sure what a use of (2) would 
look like, but (1) certainly looks ugly.

Can we just discuss how a usage would look first, and then figure out 
how to declare it?

Odd as it is, it is legal to say something like
      priority="#<=10,#=30, #>=40, #45:50"

I see that as a worst case. So I will use that to work with. I think the 
following might at least read nicely:

	<servcaps>
	   <priority max=10/>
	   <priority value=30/>
	   <priority min=40/>
	   <priority min=45 max=50>
	</servcaps>

An advantage of the above is that the simple cases really are simple.
What do you think of that?

	Paul