Subject: RE: [Fwd: RE: Does the First Line of SDP need a newline]

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 14 Mar 2001 16:51:56 -0500

The ABNF is already correct.  This just points out that the
LBRKT has trailing whitespace, so that the Megaco parser
consumes trailing whitespace, and the SDP parser starts
at the first (usually "v=" token).  That is what the ABNF
says now.

Brian

> -----Original Message-----
> From: Lee Newman [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 9:03 AM
> To: Christian Groves; Rosen, Brian
> Cc: megaco ietf
> Subject: RE: [Fwd: RE: Does the First Line of SDP need a newline]
> 
> 
> I think that if we add text like this to the implemntor's 
> guide that the
> ABNF should be changed to match it.  In no case should there 
> be exceptions
> to the ABNF grammar.  It will only lead to confusion.
> 
> Lee
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> Christian Groves
> > Sent: Tuesday, March 13, 2001 9:35 PM
> > To: Rosen, Brian
> > Cc: megaco ietf
> > Subject: Re: [Fwd: RE: Does the First Line of SDP need a newline]
> >
> >
> > Yes the implementors' guide can have implementation notes as well as
> > errata.
> >
> > Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > I've always been a little confused about if the 
> "Implementor's Guide"
> > > is allowed to have implementation guidance in addition to errata.
> > >
> > > If it is how about:
> > >
> > > Referring to section 7.1.8 and the ABNF for Local/Remote,
> > > SDP disallows whitespace at the beginning of a line, Megaco
> > > ABNF allows whitespace before the beginning of the SDP in the
> > > Local/Remote descriptor.  Parsers should accept whitespace
> > > between the LBRKT following the Local/Remote token and 
> the beginning
> > > of the SDP.  Generators should send a newline prior to the
> > > beginning of the SDP.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:[email-masked]]
> > > > Sent: Tuesday, March 13, 2001 12:56 AM
> > > > To: megaco ietf
> > > > Subject: [Fwd: RE: Does the First Line of SDP need a newline]
> > > >
> > > >
> > > > G'Day Brian, Paul or Tom,
> > > >
> > > > How do you propose to capture this in the Implementors'
> > > > guide? ie. what
> > > > text do you want added.
> > > >
> > > > Cheers, Christian
> > > >
> > > > -------- Original Message --------
> > > > Subject: RE: Does the First Line of SDP need a newline
> > > >    Date: Tue, 6 Mar 2001 11:04:06 -0600
> > > >    From: "Paul Long" <[email-masked]>
> > > >      To: "megaco" <[email-masked]>
> > > >
> > > >  Tom,So is the consensus that both of the examples in 
> Brian's first
> > > > posting to this thread are perfectly valid (that's what 
> I think) but
> > > > that it might be prudent for an entity to encode "{v=" 
> in case the
> > > > receiving entity isn't compliant in this regard? Or 
> should an entity
> > > > encode it as "{\nv="? IOW, which do you think is the 
> more conservative
> > > > and therefore interoperable encoding?Paul LongipDIalog, Inc.
> > > >
> > > >      -----Original Message-----
> > > >      From: [email-masked]
> > > >      [mailto:[email-masked]]On 
> Behalf Of Tom-PT
> > > >      Taylor
> > > >      Sent: Tuesday, March 06, 2001 4:26 AM
> > > >      To: Rosen, Brian; 'Chuong Nguyen'; megaco
> > > >      Subject: RE: Does the First Line of SDP need a newline
> > > >
> > > >      Sounds good to me.  It's an issue for Megaco 
> parsers, not SDP
> > > >      parsers, because it is up to the Megaco parser to 
> present the
> > > >      SDP to the SDP parser in the form it expects it.
> > > >
> > > >           -----Original Message-----
> > > >           From: Rosen, Brian [mailto:[email-masked]]
> > > >           Sent: Wednesday, February 21, 2001 1:18 PM
> > > >           To: 'Chuong Nguyen'; megaco
> > > >           Subject: RE: Does the First Line of SDP need a
> > > >           newline
> > > >
> > > >           I think we have consensus that the SDP spec requires
> > > >           no whitespace,but David Stonehouse points out that
> > > >           it's the Megaco part that hastrailing whitespace
> > > >           after the LBRKT, so, in theory, the SDP parserwould
> > > >           not see the whitespace. Tom Taylor, you might want
> > > >           to make this call, but I think that we ought to
> > > >           say,allowed, but discouraged, ie don't send it, but
> > > >           accept it.Brian
> > > >
> > > >                -----Original Message-----
> > > >                From: Chuong Nguyen
> > > >                [mailto:[email-masked]]
> > > >                Sent: Wednesday, February 21, 2001 12:31
> > > >                PM
> > > >                To: megaco
> > > >                Subject: Re: Does the First Line of SDP
> > > >                need a newline
> > > >
> > > >                We do the same thing too.
> > > >                We checked last year and it is in the SDP
> > > >                spec.
> > > >
> > > >
> > > >
> > > >                Sophia Scoggins wrote:
> > > >
> > > >               >  We use a third-party SDP parser which
> > > >               >  requires SDP starting at a new line. Is
> > > >               >  it specified in SDP spec?
> > > >               >
> > > >               >  "Rosen, Brian" wrote:
> > > >               >  >
> > > >               >  > Is this legal?
> > > >               >  >
> > > >               >  >         Add=termA { Media { Local {v=0
> > > >               >
> > > >               >  > m=....
> > > >               >  >
> > > >               >  > or does is HAVE to be
> > > >               >  >            Add=termA { Media { Local {
> > > >               >
> > > >               >  > v=0
> > > >               >  > m=...
> > > >               >  >
> > > >               >  > Inquiring minds want to know!!!
> > > >               >  >
> > > >               >  > Brian
> > > >
> > > >                --
> > > >                  Alcatel USA, Inc             Internet:
> > > > [email-masked]
> > > >                  1000 Coit Road Plano, Texas 75075
> > > > Phone:    (972) 519-4613
> > > >                  **** The opinions expressed are not those of
> > > > Alcatel USA, Inc ****
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
>