[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Sip-199-02: majors and nits from Robert (was: RE: WGLC for draft-ietf-sip-199-02)
Hi Hadriel,
>Sure we make mistakes just like anyone,
So, soon people will have to start deploying SBCs, in order to fix the
mistakes made by their existing SBCs..... ;)
>though with regard to MUST NOT's we follow them more often than I think
we ought to, ironically.
>But no I was not referring to us - I was referring to the (rather
common) situation where a device does not follow a SHOULD NOT, and
because it was a SHOULD instead of MUST strength they get away with
>claiming it was not required to be followed.
>
>Maybe it's just me who sees this happening? That's certainly possible
and if so I'll shut up about it.
I've seen lots of funny stuff during the years also.
But, I think the correct way to prevent those is to make sure our specs
are clear enough, and easy to understand - not to start making
restrictions which may shoot back later.
Regards,
Christer
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> Sent: Monday, November 24, 2008 1:25 AM
>
> So, YOUR developers are the ones who are stupid? ;)
>
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
> > Sent: 22. marraskuuta 2008 19:35
> > To: Christer Holmberg
> > Cc: SIP IETF
> > Subject: RE: [Sip] Sip-199-02: majors and nits from Robert
> > (was: RE: WGLC for draft-ietf-sip-199-02)
> >
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> > > Sent: Saturday, November 22, 2008 7:55 AM
> > >
> > > I don't like must-nots if it doesn't break the protocol.
> > But, I agree
> > > we should strongly recommend against it.
> >
> > Developers and product managers read SHOULD NOT as basically
> > optional, and customers have a hard time forcing vendors to follow
> > SHOULDs compared with MUSTs. We've seen this time and time again.
> > The _protocol_ may not "break", but user expectations and experience
> > "breaks", and at the end of the day that hurts all of us. Well, it
> > doesn't hurt me right now
> > - it's created a market opportunity for SBCs to go and fix it; but
> > having middleboxes fix bad implementations is not good in the long
> > term for SIP.
> >
> > IMO interoperability isn't just about _protocol_ behavior, it's the
> > resultant user experience too. Legitimate call attempts must
> > succeed. The spice must flow. ;)
> >
> > -hadriel
> >
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip