Subject: Re: [RE: Message Header w/Version]

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Aug 1999 14:52:51 -0400

Got it.

I'm okay with what you propose: TPKT for TCP.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, August 13, 1999 2:33 PM
> To: [email-masked]
> Subject: Re: [RE: Message Header w/Version]
>
>
> You don't need it for ALF, because UDP delivers messages, not streams.
>
> > -----Original Message-----
> > From: Brian Rosen [SMTP:[email-masked]]
> > Sent: Friday, August 13, 1999 2:41 PM
> > To:   Taylor, Tom-PT [CAR:B901-I:EXCH]
> > Cc:   [email-masked]
> > Subject:      RE: [RE: Message Header w/Version]
> >
> > What are you proposing for ALF?
> >
> > While I don't think that it adds much, I'm not very
> > excited about this either way.  Once again, it's in every
> > transaction, but it's also only ?2 bytes.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > Sent: Friday, August 13, 1999 2:21 PM
> > > To: [email-masked]
> > > Subject: Re: [RE: Message Header w/Version]
> > >
> > >
> > > My developers would strongly support the use of a length
> > > field in the TCP
> > > case.  I propose we specify the use of TPKT (RFC 1006) as
> > > H.323 does.  I've
> > > mentioned this before.
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [SMTP:[email-masked]]
> > > > Sent: Friday, August 13, 1999 11:18 AM
> > > > To:   [email-masked]
> > > > Subject:      Re: [RE: Message Header w/Version]
> > > >
> > > > So?  I don't think that is a problem.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Nissim Buskila [mailto:[email-masked]]
> > > > > Sent: Friday, August 13, 1999 10:57 AM
> > > > > To: Brian Rosen; Nissim Buskila
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [RE: Message Header w/Version]
> > > > >
> > > > >
> > > > > What about streaming protocols like TCP??? You would have to
> > > > > parse the whole
> > > > > message before you know it ends...
> > > > >
> > > > > Nissim.
> > > > >
> > > > > Brian Rosen <[email-masked]> wrote:
> > > > > > I do not believe we need a message size, other than
> > > that provided by
> > > > > whatever transport protocol specifies.
> > > > >
> > > > > Brian
> > > > > ------------
> > > > > Brian Rosen, Principal Engineer
> > > > > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
> > > > > (724) 742-6826  mailto:[email-masked]
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Nissim Buskila [mailto:[email-masked]]
> > > > > > Sent: Thursday, August 12, 1999 1:45 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Re: Message Header w/Version
> > > > > >
> > > > > >
> > > > > > What about the message size??? There should be a some place
> > > > > > in the header that
> > > > > > contains the total transaction message size. Maybe this
> > > > > > should only exist in
> > > > > > TCP.
> > > > > >
> > > > > > Nissim Buskila
> > > > > >
> > > > > >
> > > > >
> > >
> ----------------------------------------------------------------------
> > > > > > The issue is to allow a parser to find out quickly which
> > > > > > version tree it
> > > > > > should go down to parse the rest of the message. If the
> > > > > > protocol version is
> > > > > > on every message, then it can decide immediately. If the
> > > > > > parser has to parse
> > > > > > and understand who the sender of the message is, and then
> > > > > > find out which
> > > > > > version of the protocol that sender has said in
> ServiceChange
> > > > > > that it will
> > > > > > be using, the parser wastes time.
> > > > > >
> > > > > > This seems to be a good argument for putting the protocol
> > > > > > version back on
> > > > > > each Megaco message. Note that all commands in a message
> > > > > > would be assumed to
> > > > > > be of the same version of the protocol.
> > > > > >
> > > > > > Nancy
> > > > > >
> --------------------------------------------------------------
> > > > > > ------------
> > > > > > Nancy M. Greene
> > > > > > Internet & Service Provider Networks, Nortel Networks
> > > > > > T:514-271-7221 (internal:ESN853-1077)
> > > E:[email-masked]
> > > > > >
> > > > > > > ----------
> > > > > > > From:         Christopher Ross[SMTP:[email-masked]]
> > > > > > > Sent:         Wednesday, August 04, 1999 4:51 PM
> > > > > > > To:   [email-masked]
> > > > > > > Subject:      Re: Message Header w/Version
> > > > > > >
> > > > > > > I definitely agree.
> > > > > > >
> > > > > > > In the first version of MEGACO the space is pretty much
> > > > > > wasted, I agree.
> > > > > > > In
> > > > > > > future versions tho, there would be no way to understand
> > > > > > the message if
> > > > > > > the new
> > > > > > > version was substantially different from the first.  HTTP
> > > > > > and SIP (to
> > > > > > > mention a
> > > > > > > few) place version at the front to allow for future
> > > > > > expansion.  I think
> > > > > > > that it
> > > > > > > would be wise to add it now... while we still can.
> > > > > > >
> > > > > > > This is a snippet of a real HTTP interaction... just to
> > > > > > show how HTTP does
> > > > > > > it.
> > > > > > > (My typing is in bold, for those with HTML browsers)
> > > > > > >
> > > > > > > A valid transaction
> > > > > > >
> > > > > > >      [cross@lotus]> telnet www.yahoo.com 80
> > > > > > >      Trying 204.71.200.68...
> > > > > > >      Connected to www.yahoo.com.
> > > > > > >      Escape character is '^]'.
> > > > > > >      GET /index.html HTTP/1.0
> > > > > > >
> > > > > > >      HTTP/1.0 200 OK
> > > > > > >      Content-Length: 9989
> > > > > > >      Content-Type: text/html
> > > > > > >
> > > > > > >      <html><head><title>Yahoo!</title>
> > > > > > >
> > > > > > > An error transaction...
> > > > > > >
> > > > > > >      [cross@lotus]> telnet www.yahoo.com 80
> > > > > > >      Trying 204.71.200.68...
> > > > > > >      Connected to www.yahoo.com.
> > > > > > >      Escape character is '^]'.
> > > > > > >      GET x.html HTTP/1.0
> > > > > > >
> > > > > > >      HTTP/1.0 404 Not Found
> > > > > > >      Content-Type: text/html
> > > > > > >
> > > > > > >      <head><title>Yahoo - Document Not Found</title>
> > > > > > >
> > > > > > > I think that we should follow this method as closely as
> > > > > > possible...  (even
> > > > > > > for
> > > > > > > the status and error messages)  it is clean and
> extensible.
> > > > > > >
> > > > > > > -Chris Ross
> > > > > > >
> > > > > > >
> > > > > > > Abdallah Rayhan wrote:
> > > > > > >
> > > > > > > > I know this has been raised before and there has
> > > been alot of
> > > > > > > > discussion about ServiceChange. However, I feel
> that I need
> > > > > > > > to raise the Version issue again but not to repeat the
> > > > > discussion
> > > > > > > > about ServiceChange.
> > > > > > > >
> > > > > > > > Version is important for backward compatibility
> between the
> > > > > > > > current version of megaco and future ones. When
> you parse
> > > > > > > > you dont want to be half the way in the message before
> > > > > > > > realizing that it is a different version than what
> > > you thought.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > >
>

---

From: Chip Sharp <[email-masked]>
Date: Mon, 16 Aug 1999 14:55:05 -0400

FWIW,
HTTP 1.0 doesn't define this.  In looking at a packet trace of HTTP 1.0, it
seems to make judicious use of the PUSH bit.

Chip

> > > > > > > > > realizing that it is a different version than what

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------