Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02

From: [email-masked]
Date: Tue, 4 Nov 2003 15:35:40 +0200

Hi,

Inline

> >> lists this is not that trivial. One option is to add negation as !
> >> mark into value string like: <methods>INVITE, !MESSAGE</methods>. 
> >> Other alternative would be to redesign these lists bit differently 
> >> like:
> >>
> >> <methods>
> >>     <method>INVITE</method>
> >>     <method negated="true">MESSAGE>
> >> </methods>
> >> Second alternative is bit heavier one but I still think it is the
> >> better one.
> > 
> > 
> > The first seems more convenient, to read, to generate, and
> to process.
> 
> I prefer the second, actually. Generally, the reason is that
> it avoids 
> another layer of parsers to be implemented. The callee caps syntax is 
> not a pride point in design; its ugliness needed because of the 
> constraints of encoding the information as header parameters. XML 
> gives you a rich structure. Why bother defining a new syntax 
> for lists 
> within an element, when you can use XML natively to do that? 
> Similarly, I would do negation with an attribute, rather than include 
> the ! within the value. Also, I don't see the need for a methods tag 
> AND a method tag. Why not:
> 
> <method>INVITE</method>
> <method negated="true">MESSAGE</method>

I would also go for second option basically with same reasoning what
Jonathan provided. 
Initial idea in using both <methods> and <method> was to collect all
<method> elements into a single place. Probably this isn't needed so for
my part <methods> can go.
 
> > 
> > So it is important to preserve the semantic of whether a particular 
> > value is to be compared in a case sensitive or case insensitive way.
> > 
> > So I think I agree with your 2nd alternative in (2) above - we need 
> > something in the xml structure to indicate this. Because
> tokens are more
> > frequently used than strings, it probably makes sense for
> the default to
> > be tokens.
> 
> I would rather propose that you have this as part of the xml element
> itself, and so instead of using "other-tag", instead have "token", 
> "string", "range" etc. as elements:
> 
> <method>INVITE</method>
> <string name="new-string">Foobar</string>
> <token name="new-token">ball</token>

Yes, why not. So what is the full list of types which would be needed? I
can come up with: token, string, range, integer and boolean. Are there
any others?
  
> > 
> > Note that string comparison is different than token comparison in 
> > another way - commas in strings don't delimit tokens.
> > 
> > One more thing - the way numeric values are handled may enter the 
> > picture here - they are a third variant. Note that in
> theory you could
> > write something like:
> > 
> >     priority="#=5"
> > or
> >     priority="5"
> > 
> > Both are syntactically correct, but the second is a token
> rather than
> > a
> > number, and comparison rules are different. It is probably improper
> > usage to mix the two notations for the same parameter 
> value, but a piece
> > of code that doesn't know the particular feature should
> still understand
> > how to compare.
> > 
> > ("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005").
> > 
> > Maybe could do something like:
> > 
> >      <ext:other-tag sip.methods type=token>
> >          INVITE,OPTIONS,BYE</ext:other-tag>
> >      <ext:other-tag sip.priority type=number>
> >          <=3,=5</ext:other-tag>
> >      <ext:other-tag sip.description type=string>
> >          A string, with comma</ext:other-tag>
> > 
> 
> I would prefer:
> 
> <range name="sip.priority" less-than-or-equal-to="3"/>
> <range name="sip.priority" eqeual="5"/>
> 
> to the range syntax above.

Do you mean that 'less-than-or-equal-to' and 'equal' would be parameters
and there would not be any value for <range> element? This probably can
be done but it seems to be bit inconsistent with proposed <token> and
<string> elements. How about if attributes (like equal) would be defined
as boolean attributes and then the value would be places inside element
like:
 
<range name="sip.priority" equal="true">5</range>

- Mikko

> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> 

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