[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] RE: [Sipping] Tags in respones to CANCEL WAS: Re: Question aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimura)
- To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>, "Drage, Keith (Keith)" <drage@lucent.com>
- Subject: [Sip] RE: [Sipping] Tags in respones to CANCEL WAS: Re: Question aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimura)
- From: "Drage, Keith (Keith)" <drage@lucent.com>
- Date: Wed, 6 Nov 2002 11:49:57 -0000
- Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Bob Penfield <bpenfield@acmepacket.com>, Jiri Kuthan <jiri.kuthan@fokus.gmd.de>, Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>, manoj mallik <m.manoj@ipnetfusion.com>, sip <sip@ietf.org>, tomimura@sei.co.jp, alan.johnston@wcom.com
- List-help: <mailto:sip-request@ietf.org?subject=help>
- List-id: Session Initiation Protocol <sip.ietf.org>
- List-post: <mailto:sip@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=unsubscribe>
- Sender: sip-admin@ietf.org
Having had trouble in the past with implementors following the examples rather than the core specification (not in IETF) I believe we could usefully strengthen statements in all these example documents.
I would suggest something along the lines of:
"The flows in this document represent specific examples of behaviour that is possible using RFC 3261 [list other RFCs whose functionality is used]. Other behaviours are possible and may be more or less appropriate depending on the application that is being implemented.
This document does not modify or enhance in any manner the requirements of RFC 3261 [list other RFCs], and reference should always be made to those specifications to resolve questions of required behaviour."
is added in a prominent place in all the example flow documents.
I believe there is an important place for example flows, and I certainly still have some difficulting interpreting some bits of RFC 3261 despite the massive improvement given by the rewrite (the usage of the Contact header for example), so do not take this comment as in any way trying to downgrade the importance of these documents.
Keith
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 06 November 2002 06:09
> To: Drage, Keith (Keith)
> Cc: Jonathan Rosenberg; Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj
> mallik; sip; tomimura@sei.co.jp; alan.johnston@wcom.com
> Subject: Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question
> aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji
> Tomimura)
>
>
> Keith,
>
> You are actually right. I have moved this thread to SIP now.
>
> Thanks,
>
> Gonzalo
>
> "Drage, Keith (Keith)" wrote:
> >
> > Hang on. You are discussing a set of example flows on the
> sipping list.
> >
> > That discussion should not be used to rewrite SIP.
> >
> > The example flows should merely show an example of what is
> legitimate in RFC 3261.
> >
> > If you think RFC 3261 needs fixing, then it should be
> discussed on the SIP list, which an appropriate bug fix
> finally agreed and listed.
> >
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > Sent: 05 November 2002 15:34
> > > To: Jonathan Rosenberg
> > > Cc: Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj mallik;
> > > sipping@ietf.org; tomimura@sei.co.jp; alan.johnston@wcom.com
> > > Subject: Re: [Sipping] Tags in respones to CANCEL WAS:
> Re: Question
> > > about Section 3.8
> ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji
> > > Tomimura)
> > >
> > >
> > > Hi,
> > >
> > > Let's try to finish this discussion. Summarizing:
> > >
> > > Should the 200 OK responses to CANCEL have a To tag?
> > >
> > > Reasons for NO:
> > >
> > > CANCEL is hop-by-hop, and therefore, 200 OK responses for
> CANCEL are
> > > also hop-by-hop. If we look at 100 Trying responses, which are
> > > hop-by-hop as well, we see that they do not have a tag.
> > >
> > > Reasons for YES:
> > >
> > > Final responses to any request have tags. Even non-2xx
> final responses
> > > for INVITE, which are hop-by-hop, have a tag.
> > >
> > > Note that user agents and proxies will have to be
> prepared to receive
> > > 200 OK responses for CANCEL with or without tags anyway,
> to improve
> > > interoperability. So, this is not a big deal after all. Our
> > > decision is
> > > only useful as long as it helps develop a coherent spec.
> > >
> > >
> > > I would suggest to go for YES, document it, and move on.
> > >
> > > Comments?
> > >
> > > Thanks,
> > >
> > > Gonzalo
> > > _______________________________________________
> > > Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> >
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip