Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

[Takuya Sawada <[e-mail]>]

Hi, Brett,

I think I see your points, too.
As Paul also said, we will be happy and incorporate it if you could
provide the text to be added or modified.

Regards,
Takuya


> Brett,
> 
> I think I agree with your points. Can you propose text that will satisfy 
> your concerns?
> 
> 	Thanks,
> 	Paul
> 
> Brett Tate wrote:
> >> How about Brett's proposal on PRACK 488?
> >> I don't think we can reach the consensus 
> >> on PRACK 488 behaviour.  Christer proposed to 
> >> make separate document to define 'new' normative 
> >> behaviour. We may need more discussion.
> >> Then IMO, for the time being, 
> >> "PRACK request should not be rejected"
> >> approach seems to be good and Christer's text 
> >> and proposal can hopefully cover your concern.
> > 
> > Christer's proposed text does not satisfy my concern.  It potentially
> > makes it worse since the wording is unclear about which aspect (if any)
> > "violates current rules".  I think the violation is thinking that the
> > response satisfactorily "acknowledges" the reliable response; however
> > others might think it is the sending of the 488/606.  (The UPDATE 504
> > response is discussed within rfc3311; however I'm not sure if anyone
> > would similarly send a PRACK 504 or a PRACK SDP that would cause it.)
> > 
> > I think that sipping-sip-offeranswer-05 is misleading, incomplete, or
> > inaccurate concerning PRACK 488 and "PRACK request should not be
> > rejected".  
> > 
> > Section 2.2 does not indicate the potential for PRACK 488.  Thus devices
> > might not realize that a PRACK 488 may be sent or understand would
> > should occur when received.  I have no issue with the draft discouraging
> > PRACK 488 in favor of a "rejection" SDP within PRACK 200.  However since
> > PRACK 488 can be compliantly triggered by proxies; the UAC should expect
> > 488 and realize that the 100rel might not have been satisfactorily
> > acknowledged.
> > 
> > The "PRACK request should not be rejected" statements are used without
> > providing justification or insurance that rfc3262 actually indicates
> > "PRACK request should not be rejected".
> > 
> > Section 6.1 is misleading, incomplete, or inaccurate concerning the
> > issue with and without Christer's proposed text.  PRACK 488 is valid and
> > be sent by proxies; it is an open issue concerning compliance and
> > meaning if sent by non proxy.  Thus the PRACK 488 may or may not
> > currently contradict "The current RFCs do not provide a way to reject
> > the offer and at the same time to acknowledge the reliable response".
> > It obviously satisfies the "way to reject the offer"; however it
> > requires subsequent PRACK without or with modified SDP to ensure
> > acknowledgement of reliable response.
> > 
> > 
> >>> I think the following changes should be made to 
> >>> sipping-sip-offeranswer-05.  The text can be discussed 
> >>> after rfc3262 detailed analysis by Paul, Christer, and others.
> >>>
> >>> I think that the draft should mention PRACK 488 response within 
> >>> section 2.2.
> >>>
> >>> Concerning "PRACK request should not be rejected" within 
> >>> sections 3.2 and 4.1, I don't think such a statement should be 
> >>> made without clarification somewhere concerning the reason.
> >>>
> >>> I think that the draft should mention PRACK 488 response within 
> >>> section 6.1.
> > 
> 

--------
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  http://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