Subject: RE: [Sipping] Comments on draft-sawada-sipping-sip-offeranswer-01.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 7 Jul 2006 14:46:47 -0400

So, the presumption is that all behavior described as "must" or "should"
in this draft are derived from a "MUST" or "SHOULD" in an existing RFC?

Are there any cases where this is not so?

Mike

> -----Original Message-----
> From: Takuya Sawada [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 9:38 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Paul Kyzivat (pkyzivat); 
> [email-masked]
> Subject: Re: [Sipping] Comments on 
> draft-sawada-sipping-sip-offeranswer-01.txt
> 
> Hi,
> 
> > Hi,
> > 
> > a few comments on the draft below:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeransw
> > er-01.txt
> > 
> > First of all, the draft needs to be very clear about its 
> scope. This 
> > draft's scope should be to clarify aspects of how SIP uses the 
> > offer/answer model. Consequently, the idea will be to publish it at 
> > some point as an informational RFC. This means that this 
> draft should 
> > not contain normative language. So, the reference to RFC 
> 2119 should 
> > be removed. An explanation along the lines of this paragraph at the 
> > beginning of the draft would not hurt either.
> > 
> I feel we have reached the consensus that the scope of this 
> draft is for clarification of the usage and does not include 
> any extension to SIP.
> That is, it should be an informational RFC.
> 
> I agree to remove the reference to RFC 2119. We do not use no 
> capital keywrods like "MUST" or "SHOULD" in the draft.
> 
> > In the process of discussing this draft, we will most likely find 
> > offer/answer aspects that are underspecified or that need 
> to be fixed 
> > (a few cases have already been identified in the mailing 
> list discussions).
> > The role of this draft is not to fix those. We have to 
> options. We can 
> > document the issue and publish this draft or we can generate a 
> > normative document fixing the issue, and only then publish 
> this draft 
> > referencing that new document. The best option will depend on the 
> > particular case at hand.
> > 
> I prefer the former option.
> It is also important to make some issues clear and document 
> them before we tackle them.
> > 
> > A comment on the Introduction. It says: "Unless defined in an RFC 
> > explicitly as an offer or an answer, except ones in non-reliable 
> > provisional response to INVITE request, a session 
> description should 
> > not be included in SIP messages to avoid confusions".
> > 
> > As pointed out in Section 1.3, some SIP messages can carry session 
> > descriptions that are not offers or answers. Therefore, the 
> paragraph 
> > above needs to be rephrased.
> > 
> I think we can just remove the above sentense.
> How to avoid confusion is described inside this draft. 
> Such a statement does not need to be here.
> > 
> > Regarding the interest of the SIPPING WG to work on this document, 
> > based on the mailing list discussions, it is clear that there is a 
> > great deal of interest to clarify the topics this draft deals with. 
> > So, this draft is a very good candidate to become a SIPPING working 
> > group item in the future (as soon as we finish some of the stuff we 
> > currently have on our plate). This is an excellent example of how a 
> > draft can be discussed and even adopted as a WG item 
> without a face-to-face presentation.
> > 
> We will update the draft along with the discussions held in 
> the SIPPING ML, as an individual draft.
> Then, please discuss whether to adopt it as a WG item and how/when.
> 
> > Cheers,
> > 
> > Gonzalo
> > 
> Thanks,
> 
> Takuya
> 
> > _______________________________________________
> > 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
> 
> --------
> Takuya Sawada
> KDDI Corporation (KDDI)
> Garden Air Tower, 3-10-10, Iidabashi,
> Chiyoda-ku, Tokyo 102-8460, Japan
> Tel: +81-3-6678-2997
> Fax: +81-3-6678-0286
> [email-masked]
> 
> 
> _______________________________________________
> 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: Takuya Sawada <[email-masked]>
Date: Tue, 11 Jul 2006 22:43:51 +0900

I did not check all but some "must" or "should" are conditional.
That is, as some may be explicitly stated and others may not, it is like

"if UA wants to avoid such a comlexity, UA should do this..."

In such a case, not all the "must"/"should" are not necessarily 
derived directly from the existing RFCs. 
And also, some "should" are used for expressing not so strict meaning
defined as in RFC 2119.
Anyway, we are careful not to violate or extend the existing rules.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)