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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Mar 2001 09:40:27 -0500

Usually, at least in the IETF, we try to have a rule that is usually phrased
as "be strict
in what you send, liberal in what you accept".  In this case, there is no
requirement for
the newline, but it is probably best, as guidance, to use "should send a
newline...",
and for recievers to not depend on it.  Thus, I think the wording should
stand.
 
Brian

-----Original Message-----
From: David Stonehouse [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 8:45 AM
To: 'Christian Groves'
Cc: 'Rosen, Brian'; megaco ietf; Tom-PT Taylor
Subject: RE: [Fwd: RE: Does the First Line of SDP need a newline]

Christian, 

Everything up to the last sentence fits my definition of a clarification.
The last interop proved that not everyone had a common understanding, so it
is a good addition to the implementors' guide.  However, saying "generators
should send a newline prior to the beginning of the SDP" is more than a
clarification - it is recommending a choice of implementation between two
viable options for message format.  This seems like a slippery slope to me.

Dave 

-----Original Message----- 
From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, March 27, 2001 11:31 PM 
To: Stonehouse, David [NC1:GW10:EXCH] 
Cc: 'Rosen, Brian'; megaco ietf; Taylor, Tom-PT [NORSE:B881:EXCH] 
Subject: Re: [Fwd: RE: Does the First Line of SDP need a newline] 

G'Day Dave, 

I'm not strong on this either way. Currently I have it captured in the 
Implementors' guide additions as a clarification: 

1.32 First Line of SDP a newline 

Description:    There is confusion in the ABNF encoding with regards to the 
use of a new line as the first line of the SDP. The clarification below 
seeks to clarify this. 
Reference:      Subject: RE: [Fwd: RE: Does the First Line of SDP need a 
newline] 
Date: Tue, 13 Mar 2001 09:13:57 -0500 
From: "Rosen, Brian" <[email-masked]> 
To: "'Christian Groves'" <[email-masked]>, megaco ietf 
<[email-masked]> 
 [Begin Clarification] 
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. 
[End Clarification] 

So i'll leave it up to Tom et all to figure if it goes in or not. 

Cheers, Christian 

David Stonehouse wrote: 
> 
> Sorry for the late response on this.  This is a bad thing to add to 
> the implementors' guide.  I am seeing a split in what people have 
> chosen to do regarding the format of the Local/Remote descriptor, and 
> there should not be any validation of either approach in the 
> implementor's guide.  If either group has failed to create a parser 
> that can't handle the other, than they should have every encouragement 
> to go back and fix their parser to be  compliant with the ABNF.  To 
> put in a phrase like "Generators should" will only serve to benefit 
> someone who has taken shortcuts with their implementation of the 
> grammar. 
> 
> Dave 
> 
> -----Original Message----- 
> From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, March 13, 2001 9:14 AM 
> To: 'Christian Groves'; megaco ietf 
> Subject: RE: [Fwd: RE: Does the First Line of SDP need a newline] 
> 
> 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]
<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]
<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]
<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]
<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 **** 
> > 
> > 
> > 
> > 
> >