Re: [Sipping] can update be used in Figure 4indraft-ietf-sipping-sip-offeranswer-06

[Takuya Sawada <[e-mail]>]

Yes, I see. Thanks.
And the subsequent references will also be changed, if any.

Regards,
Takuya

> I think the changes you propose seem good. One comment: your replacement
> text includes a reference to Figure 5. Since you propose to remove
> figure 4 and renumber, this too will need to be renumbered to be Figure 4.
> 
> 	Thanks,
> 	Paul
> 
> Takuya Sawada wrote:
> > Hi,
> > 
> > I found the discussion below.
> > 
> > http://www.ietf.org/mail-archive/web/sipping/current/msg14479.html
> > 
> > Yes, I agree. Figure 4 is not adequate. It could not be happened.
> > Some texts in the same section should also be modified.
> > 
> > How about the following changes;
> > 
> > - Remove Figure 4 and renumber the subsequent figures.
> > - Remove the following sentence
> >   'Therefore, to simplify implementations, a UA acting
> >   as a UAS for an INVITE transaction is recommended not to defer
> >   sending an UPDATE request with an offer until after the reliable
> >   response with an answer to the offer in the INVITE request is
> >   acknowledged with a PRACK request.'
> >   (I know 'not to defer' should've been 'to defer' )
> >   And probably put the sentence like
> >   'Fortunately, under the current rules, UA A can not send a new
> >    offer until the reliable response.'
> > - Chane the NOTE on Table 3
> >   <Old>
> >   'NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily
> >   avoidable. See Figure 4 and Figure 5.'
> >   <New>
> >   'NOTE: 1xx-rel/2xx case is extremely rare case and easily
> >   avoidable. See Figure 5.'
> > - In Table 3
> >   <Old>
> >   -------+------------------------------+--------------------------
> >   PRACK  | Not a pattern 4. in Table 1. | Delay sending response
> >          | 1xx-rel must have an answer, | until answer1 is received
> >          | not an offer.                |
> >   -------+------------------------------+--------------------------
> >   <New>
> >   -------+------------------------------+--------------------------
> >   PRACK  | This case never happens      |        -
> >          | under the current rules.     |
> >   -------+------------------------------+--------------------------
> > 
> > Please comment.
> > 
> > Regards,
> > Takuya
> > 
> >> It appeared first in -04 if that helps (November 07).
> >>
> >> I don't remember why it got introduced either.
> >>
> >> I agree that 3311 is pretty clear that this is a protocol violation  
> >> rather than a race-condition.
> >>
> >> RjS
> >>
> >> On Feb 28, 2008, at 10:58 AM, Paul Kyzivat wrote:
> >>
> >>> I saw your query. When I looked back at 3311 it does seem to support
> >>> your position. I can't remember why we included this case.
> >>>
> >>> Does anybody else remember?
> >>>
> >>> 	Paul
> >>>
> >>> Rockson Li (zhengyli) wrote:
> >>>> Paul,
> >>>>
> >>>> Do you have any comments on this?
> >>>>
> >>>> Regards,
> >>>> -Rockson
> >>>>
> >>>> --------------------------------------------------------------------- 
> >>>> ---
> >>>> *From:* Rockson Li (zhengyli)
> >>>> *Sent:* Tuesday, February 26, 2008 3:26 PM
> >>>> *To:* [e-mail]
> >>>> *Subject:* can update be used in Figure 4 in
> >>>> draft-ietf-sipping-sip-offeranswer-06
> >>>>
> >>>> In Figure 4 of draft-ietf-sipping-sip-offeranswer-06
> >>>>
> >>>> UPDATE is used to send new offer from Callee A.
> >>>>
> >>>> However, I  wonder if it's valid to be used here? since as per  
> >>>> RFC3311
> >>>> sec5.1
> >>>>
> >>>> and for the callee:
> >>>>
> >>>>       o  If the UPDATE is being sent before the completion of the  
> >>>> INVITE
> >>>>          transaction, and the initial INVITE contained an offer, the
> >>>>          UPDATE cannot be sent with an offer unless the callee has
> >>>>          generated an answer in a reliable provisional response,  
> >>>> <NOTE>has
> >>>>          received a PRACK for that reliable provisional response</ 
> >>>> NOTE>, has
> >>>>          not received any requests (PRACK or UPDATE) with offers  
> >>>> that it
> >>>>          has not answered, and has not sent any UPDATE requests
> >>>>          containing offers that have not been answered.
> >>>>
> >>>> Any comments?
> >>>>
> >>>> Regards,
> >>>> Rockson Li
> >>>>
> >>>> Cisco R&D Center, Shanghai, PRC
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> >>> This list is for NEW development of the application of SIP
> >>> Use [e-mail] for questions on current sip
> >>> Use [e-mail] for new developments of core SIP
> >> _______________________________________________
> >> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use [e-mail] for questions on current sip
> >> Use [e-mail] 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: [phone]
> > Fax: [phone]
> > [e-mail]
> > 
> > ------------------------------------------------------------------
> > 注意：この電子メールには、KDDI株式会社の機密情報が含まれている
> >       場合が有ります。正式なメール受信者でない場合、メール複製、
> > 　　　再配信または情報の使用を固く禁じております。
> >       エラー、手違い等でこのメールを受け取られましたら、お手数を
> > 　　　おかけ致しますが、削除を行い配信者に連絡をお願い致します。
> > NOTE: This electronic mail message may contain confidential and
> > 　　　privileged information from KDDI Corporation. If you are
> > 　　　not the intended recipient, any disclosure, photocopying,
> >       distribution or use of the contents of the received
> >       information is prohibited. If you have received this e-mail
> >       in error, please notify the sender immediately and
> >     　permanently delete this message and all related copies.
> > -------------------------------------------------------------------
> > 
> > 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] 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: [phone]
Fax: [phone]
[e-mail]

------------------------------------------------------------------
注意：この電子メールには、KDDI株式会社の機密情報が含まれている
      場合が有ります。正式なメール受信者でない場合、メール複製、
　　　再配信または情報の使用を固く禁じております。
      エラー、手違い等でこのメールを受け取られましたら、お手数を
　　　おかけ致しますが、削除を行い配信者に連絡をお願い致します。
NOTE: This electronic mail message may contain confidential and
　　　privileged information from KDDI Corporation. If you are
　　　not the intended recipient, any disclosure, photocopying,
      distribution or use of the contents of the received
      information is prohibited. If you have received this e-mail
      in error, please notify the sender immediately and
    　permanently delete this message and all related copies.
-------------------------------------------------------------------

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP