----- Original Message -----
From: Sean Olson <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, April 20, 2000 6:54 PM
Subject: Re: Lessons learned...
> > 4) SDP is still causing some problems.
> > ....
> > Also, something that was recently pointed out to me: SDP is
> > required to include at least one of a p= or e= line. On page
> > 11 of RFC2327, it says:
> >
> > "Either an email field or a phone field must be specified.
> > Additional email and phone fields are allowed."
> >
>
> This is at odds however with the list starting on page 6 which indicates
that
> p and e are both optional fields. Also, in the spirit of being forgiving,
I
> hope that all SDP implementations will accept an SDP body without either a
p= or
> e= line. Furthermore, these fields should be taken with a grain of salt. I
> don't see much purpose in rejecting an SDP body because the p= field
contains a
> malformed phone number or the e= field contains a malformed e-mail field.
These are
> informative but not really authoritative.
>
> Sean Olson
> --
Yes - if SDP contradicts itself, then it is SDP that needs fixing.
As a general point, about the need for parsers to be forgiving - there is an
argument that 'over-aggressive' parsers are useful because
1) they flag problems with a standard or its implementation(s)
2) they prevent unpredictable and potentially serious operational problems
from arising in a complex interworking environment.
Barry Desborough, VegaStream Limited
[EMAIL PROTECTED]
