Re: 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:[email protected]]
> Sent: Monday, November 24, 2008 1:25 AM
>
> So, YOUR developers are the ones who are stupid? ;)
>
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:[email protected]]
> > 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:[email protected]]
> > > 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip