Subject: [Sipping] Review of: draft-allen-sipping-poc-p-answer-state-header-00.txt

From: Dean Willis <[email-masked]>
Date: Mon, 18 Jul 2005 12:13:26 -0500

I received a request from OMA that we perform expert review of the  
revised p-answer-state header draft.

Please have a look at:

http://www.ietf.org/internet-drafts/draft-allen-sipping-poc-p-answer- 
state-header-00.txt

and raises any issues to the list ASAP.

We'll need a volunteer or two to do the actual review. Any takers?

Note:

idnits has the following minor things to say about this draft that will  
have to be changed before it could go to the IESG:

   * There are 54 instances of too long lines in the document, the  
longest
     one being 5 characters in excess of 72.

   Miscellaneous warnings:

   - Line 200 has weird spacing: '...that it  is...'
   - Line 310 has weird spacing: '...er mode  setti...'
   - Line 456 has weird spacing: '...request  in re...'
   - Line 477 has weird spacing: '...med" in  the r...'
   - Line 478 has weird spacing: '...e" from  the f...'
   - (3 more instances...)

--
Dean

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2005 14:56:33 -0400

> We'll need a volunteer or two to do the actual review. Any takers?

I don't have time to go over it with a fine tooth comb. But I did read 
it over and have the following comments:

There are a number of places where there is wording similar to "if the 
response contains SDP". This isn't an accurate characterization of the 
proper condition. I believe this may be more correctly stated as "if the 
response contains an answer". Reasons for this change:
- An answer might be represented in SDPng rather than SDP
- a response could contain SDP that is an offer rather than
   an answer
- a response could contain SDP that is neither offer nor answer
   (using some other Content-Disposition.)

When mentioning that the P-Answer-Mode may be in a NOTIFY, please 
clarify that it is in the sipfrag body carried in the NOTIFY, not in 
amonst the NOTIFY headers. (This is already done in a few places, but 
not nearly all.)

There is a lot of mention of "an intermediate node that acts as a 
back-to-back user agent". However B2BUA behavior is not standardized, so 
B2BUAs may act in a multitude of roles. The B2BUAs mentioned in this 
draft have a special role and special responsibilities. (There could be 
other B2BUAs in the call that act more like proxies as far as this draft 
is concerned.) The draft should distinguish those elements to which it 
intends normative behavior to apply, rather than simply applying to to 
"B2BUA", or "intermediate node" generically. To achieve this I think it 
will be necessary to assign a name to the component types whose behavior 
is being specified. (E.g. PoC-Intermediate.)

Is P-Answer-Mode only used with initial INVITEs? Or can it be applicable 
to reINVITEs as well? At first glance it would seem to only be 
applicable to initial invites. But there may be cases where it would be 
applicable. E.g. a blind transfer done in 3pcc mode might result in a 
new participant being in unconfirmed mode for a time. I don't know the 
answer here, but some discussion of the issue would be helpful. A state 
model for confirmation state over the lifetime of a dialog could help.

	Paul

>   * There are 54 instances of too long lines in the document, the  longest