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

From: [email-masked]
Date: Mon, 1 Nov 2004 09:59:16 +0200

> 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"

Yes, it is a bit odd. 

> 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?

Yes, that doesn't look bad at all. I would still like to add bit more syntax into it as follows:

<servcaps>
	<priority>
		<range max="10"/>
		<equals val="30"/>
		<range min="40 max="50"/>
	</priority>
</servcaps>

or

<servcaps>
	<priority>
		<less max="10"/>
		<equals val="30"/>
		<more mix="40"/>
		<range min="40 max="50"/>
	</priority>
</servcaps>

This way all priority values would be enclosed inside a single <priority> element. 

- Mikko

> 	Paul
> 
> [email-masked] wrote:
> > 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
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2004 11:00:53 -0500

> Yes, that doesn't look bad at all. I would still like to add bit more syntax into it as follows:

I can live with either of these. I guess they are more in keeping with 
the overall style.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2004 11:09:21 -0500

I like the change in the representation for token-valued features, to 
the form that has <supported> and <notsupported> elements.

However, I am concerned about defining xml elements for each token. This 
begins to look like ASN.1 that most people seem to hate. It requires an 
excessive amount of schema definition, and makes it impossible to 
represent a value for which no schema definition is present.

I think it would be preferable to define them all the way <languages> is 
defined, with the individual tokens simply being defined as strings.

	Paul