Subject: RE: Query on case insensitivity

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

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

> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 11:33 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Query on case insensitivity
> 
> 
> 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
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, June 20, 2001 11:24 AM
> To: [email-masked]
> Subject: RE: Query on case insensitivity
> 
> 
> 
> 
> 
> 
> 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)
> 
> Subject:  RE: Query on case insensitivity
> 
> 
> 
> 
> 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: Terry L Anderson <[email-masked]>
Date: Wed, 20 Jun 2001 14:39:33 -0400

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.

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