Subject: RE: Query on case insensitivity

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 08:28:32 -0400

The answer to all of your queries is yes

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 1:27 AM
> To: [email-masked]
> Subject: Query on case insensitivity
> 
> 
> 
> 
> Hi all,
>      ABNF syntax notation is CASE INSENSITIVE, apart from the 
> SDP and whatever
> comes within quotes should not be validated.
> My queries:
> 1.  In case of short and long tokens can we mix both of them like
> 
>      MEGACO/1 [123.123.123.123]:55555
>           P = 50005 {
>                Context = - { N = A5555 }
> Is it allowed?
> 
> 2.  Can we have tokens like   "TranACTIONresponSEAck" , I 
> mean mix of lower and
> upper case in one token ?
> 
> 3. Can we have short tokens in lower case or mix case like  
> "rc" or "rC"  for
> ReceiveOnly ?
> 
> regards/
> Amit
> 
>

---

From: Al Varney <[email-masked]>
Date: Wed, 20 Jun 2001 10:42:24 -0500

>The answer to all of your queries is yes

    I assume your answer applies to non-tokens as well?

    For example, I can specify a 'digitMapName' of "ParisFrance" and later 
refer to it by 'parisFRANCE'?  An Event notification can refer to an event 
name in lower case, even though I originally asked for the Event report 
usng the Event name in upper case?  Package names/event names are case 
insensitive (dt, DT, dT and Dt all refer to dial tone)?  Responses can use 
different/mixed cases in any (non-SDP) string from that used in a Command?

    Or is it JUST the 'fixed' tokens of the MEGACO ABNF itself that are 
case insensitive?

> > upper case in one token ?

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 11:46:39 -0400

Yep, applies to DigitMapNames.

I was trying to come up with something that was a counter
example.  Closest I can come is the display in the IPPhone
packages.  I think the string for the value of the display
would have cases sensitivity, althought there are no comparisons
against such a property value.

Brian

> From: Al Varney [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 11:42 AM
> To: [email-masked]
> Subject: RE: Query on case insensitivity
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 11:32:06 -0400

I really think this is not a real concern, and would make
a number of tokens lose any semblance of readability.
Usually, you parse identifiers (including keywords) by
looking for the separation punctuation, and then comparing
against a dictionary (and you would, of course, convert
the identifier to a single case before you did that).  While
there are parsers that do literal state machine transitions
on every character, even they wouldn't be substantially improved
by such a restriction on token choices.

The short tokens are for link efficiency and not for parser
efficiency.  I don't think parser efficiency would be measurably
affected either way. YMMV

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 11:24 AM
> To: [email-masked]
> Hi
>  I am a bit concerned about the first point.
> Maybe its a bit too late, or simply irrelevant, but still I 
> would like to put
> forth this point.
> 
>  Allowing a message to contain a mixture of short and long tokens will
> needlessly complicate the parser.
>      For tokens like the one for Error, which has a short 
> token 'Er' and a long
> one 'Error'
> the parser would have to look ahead to the 3rd character to 
> conclude whether it
> is the shorter version of
> Error token, or it is halfway thru the long 'Error' token or 
> whether it is
> simply an syntax error. If we put a small
> restriction, that the messages should contain only one kind 
> of tokens, it would
> atleast do away with one of the possibilities.
>      Parsing is a CPU intensive process and such small 
> restrictions would be a
> major help.
>      It will make life simpler for the parser, and perhaps 
> make the messages
> more elegant.
> 
> Regards
> Shiv
> 
> 
> 
> 
> 
> "Rosen, Brian" <[email-masked]> on 06/20/2001 05:58:32 PM
> 
> To:   Amit Kalra/HSS@HSS, [email-masked]
> cc:    (bcc: Shiv Kumar/HSS)
>

---

From: [email-masked]
Date: Wed, 20 Jun 2001 23:01:55 +0530

Hi All

 I have no qualms about whether we use short tokens or long ones. Its just that
the message should
be consistent about the kind of token used.  The first token MEGACO/! should
indicate what the
following tokens are going to be like. The parser engine with a bit of extra
effort can be tuned for
maximum efficiency [ and no Troy, the state variable can be used in a better
manner than what you
 suggested :-) ]

 Adding more restrictions like say,  only Short Tokens in upper case, would
probably make the parsing
very fast. Almost as good as its binary equivalent.
 But then again, for debugging purposes, Long Text Tokens are very convenient.

Regards
Shiv

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 17:17:43 -0400

Yep, could be an issue.

Brian

> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 2:40 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Query on case insensitivity
> 
> 
> Isn't there an issue with UDP since, as I understand it, the 
> full message
> must be less than MTU (often 1400 bytes or so).  Seems that 
> with long form
> text this may more often be exceeded.  A lot of my Adds or 
> Modifies with SDP
> come close.
> 
> "Rosen, Brian" wrote:
> 
> > Debugging is considered a very good reason for long tokens.
> > Generally speaking there is NO good reason for short tokens,
> > but we were working towards no binary (which failed of course),
> > and we wanted to not have the length-of-message argument.
> > There are very few MGs on links where bandwidth is so constrained,
> > the difference between long and short tokens matters.
> > Now, if we were using Megaco on a mobile link, where we had kilobits
> > of bandwidth, maybe.
> >
> > BTW, in the end, text is proving to be shorter, and faster, than
> > binary (I think that is with short tokens but I'm not sure).
> > But we knew that, right :)
> >
> > Brian
> >
> > > From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> > > Sent: Wednesday, June 20, 2001 11:33 AM
> > > To: [email-masked]; [email-masked]
> > > Hi Shiv,all,
> > > I agree with shiv's argument. First of all, I am not clear
> > > why there are two
> > > set of tokens. The long tokens doesn't convey any extra
> > > information (except
> > > for debugging purposes). In terms of efficiency obviously the
> > > short tokens
> > > will be the better choice. And having a mix of both unnecessarily
> > > complicates the parser.
> > >
> > > Regards
> > > Madhubabu
> > >
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > [email-masked]
> > > would like to
> > > put
> > > token 'Er' and a
> > > long
> > > conclude whether
> > > it
> > > of tokens, it
> > > would
> > > restrictions would be
> > > a
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:[email-masked]
> Tel:908.582.7013   Fax:908.582.6729
> Lucent Technologies/INS/Voice Over IP Access Networks
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> 
>