Subject: Re: [Sipping] Tags in respones to CANCEL WAS: Re: Question aboutSection 3.8 ofdraft-ietf-sipping-basic-call-flows-01.txt(Eiji Tomimur a)

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 06 Nov 2002 17:37:33 +0200

Hi,

well, I was actually more interested in resolving this particular
technical issue in RFC 3261 than in discussing the merits of the
call-flow document :o)

Let's not side-track this discussion.

Any comments on the technical matter?

Gonzalo

Alan Johnston wrote:
> 
> Keith,
> 
> I appreciate your comments and would agree with them - we definitely don't
> want people coding from the call flows.  In the last revision of the call
> flows documents, I have been working on wording to try to emphasize
> this.  Here is how the Introduction now reads:
> 
> "The call flows shown in this document were developed in the design of a
> SIP IP communications network. They represent an example minimum set of
> functionality.
> 
> "It is the hope of the authors that this document will be useful for SIP
> implementors, designers, and protocol researchers alike and will help
> further the goal of a standard implementation of RFC 3261[2]. These flows
> represent carefully checked and working group reviewed scenarios of the
> most basic examples as a companion to the specifications.
> 
> "These call flows are based on the current version 2.0 of SIP in RFC
> 3261[2] with SDP usage described in RFC 3264[3]. Other RFCs also comprise
> the SIP standard but are not used in this set of basic call flows. "
> 
> and in the next section:
> 
> "This document is informational only and is NOT NORMATIVE in any sense, in
> that it does not prescribe the flows that are shown, indeed they MUST NOT
> be copied due to the reasons described in the next paragraph. On the other
> hand, the basic call flows represent well- reviewed examples of SIP usage
> that are best common practice according to community consensus.
> 
> "For simplicity in reading and editing the document, there are a number of
> differences between some of the examples and actual SIP messages. For
> example, the HTTP Digest responses are not actual MD5 encodings. Call-IDs
> are often repeated, and CSeq counts often begin at 1. Header fields are
> usually shown in the same order. Usually only the minimum required header
> field set is shown, others that would normally be present such as Accept,
> Supported, Allow, etc are not shown."
> 
> I think these changes are in the direction you mention.  As always,
> suggestions and comments are most welcome.
> 
> Thanks,
> Alan Johnston
> WorldCom
> sip:[email-masked]
> 
> At 11:49 AM 11/6/2002 +0000, Drage, Keith (Keith) wrote:
> >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: [email-masked]
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > Sent: 06 November 2002 06:09
> > > To: Drage, Keith (Keith)
> > > Cc: Jonathan Rosenberg; Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj
> > > mallik; sip; [email-masked]; [email-masked]
> > > 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: [email-masked]
> > > >
> > > > > -----Original Message-----
> > > > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > > > Sent: 05 November 2002 15:34
> > > > > To: Jonathan Rosenberg
> > > > > Cc: Bob Penfield; Jiri Kuthan; Jiri Kuthan; manoj mallik;
> > > > > [email-masked]; [email-masked]; [email-masked]
> > > > > 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 [email-masked] for questions on current sip
> > > > Use [email-masked] for new developments of core SIP
> > > >
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Wed, 06 Nov 2002 09:26:31 -0600

Keith,

and in the next section:

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 07 Nov 2002 08:52:40 -0600

[...Trimmed CC list...]

Alan Johnston wrote:
> Keith,
> 
> I appreciate your comments and would agree with them - we definitely 
> don't want people coding from the call flows.  
[...]

Alan:

I am afraid that the following sentence:

 > Header fields are usually shown in the same order.

may be construed to mean that header fields do NOT have to appear in
order.  Some do; especially Via and R-R headers in a response and Route
headers in a request.

To avoid such ambiguity, may I suggest:

    "For the sake of conformity, header fields are usually shown in
     the same order.  However, the SIP specification mandates that
     the Via and Record-Route headers maintain their positional
     values in responses and Route headers maintain their positional
     value in requests."

Please feel free to cut/slice/dice/mince the above as you see fit.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216