1. Section 6.1 includes a question whether it is OK to prohibit Send-Info/Recv-Info in re-INVITE or UPDATE, and mentions that Adam points out 3PCC needs it. I agree with Adam.
2. There is no provision for Send-Info/Recv-Info in 200/ACK (i.e. omitting from an INVITE request, in the same way that SDP offer can be omitted). It seems to me that some of the use cases that motivate INVITE without SDP offer could also motivate INVITE without Send-Info/Recv-Info. For example, a 3PCC make-call might need to do this. My remaining comments are more minor: 3. Information conveyed by INFO seems to be described in different ways, e.g: - "application level information" - "session related control information" - "mid-session signaling" - "mid-session information" We should be consistent, and my preference would be the first of these. 4. "This mechanism is not appropriate for IANA-registered Subscribe Event package types, and support for this mechanism should be explicitly indicated in future Info Package definitions and registrations." This sentence seems to be discussing two independent concepts, if I understand correctly. It should be split in two. 5. Section 4 refers to Send-Info and Recv-Info without having introduced these terms. Either they should be briefly introduced earlier or there should be a forward reference to the section where they are introduced. 6. "INFO requests may be sent in either direction, once the UAC or UAS has received the Send-Info/Recv-Info header field value indications of what the far-end supports. For the UAS, it MUST receive the ACK for the INVITE's 200-ok, or the PRACK for a provisional response, before sending an INFO request." It seems that the second sentence is in conflict with the first. Is the first sentence meant to be applicable only to a UAC? 7. I don't understand the logic behind the split between "4.2. Message Body Inclusion" and "4.5. INFO Message Bodies". 8. Section 8.1.2 talks about message volume, and in particular suggests that the mechanism is not suitable for data beyond the limits of typical SIP messages. Perhaps it would also be worth noting the likelihood of exceeding MTU size on UDP hops if large amounts of application data are included. 9. Section 8.2.3 talks about defining INFO bodies as part of Info Packages. However, elsewhere in the document it allows header fields to be used to convey application data (if I understand correctly). Shouldn't this be mentioned in 8.2 too? John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
