Inline. On Mar 3, 2009, at 12:11 PM, Bob Penfield wrote:
Here are some comments on the INFO draft: Section 2 says: Each UA enumerates which Info Packages it can receive. If the far end indicates it can receive a package offered by the near end, the near end can send INFO methods containing the payload for that package. "offered" needs to changed to "supported" since an INFO sender does not indicate what packages it can send.
Correct. Editing shrapnel. It is really in Section 1 (this is a note for me).
Section 3 is called "Info Package Negotiation", but since we removed Send-Info, it is not a negotiation since there is no feedback from the peer UA. It is simply a declaration of receive capability. At first read, I was totally confused by section 3.1 because I was expecting some actual negotiation given the above statement in Section 2. There are a few other places in the document that mentions "negotiation" that also might need to be changed.
How about "Info Package Behavior"?
I think the usage of UAC/UAS terminology in Section 3.1 is still confusing. I would prefer to see something like: A UA supporting this document MUST advertise the set of Info Packages it is willing to receive in Recv-Info header(s) in all "INVITE dialog usage" requests and responses (101-199 and 2xx only) for dialog establishment or target refresh. This includes INVITE, UPDATE, PRACK and ACK and their non-failure responses. A UA MUST NOT send INFO requests for a given INFO package until the UA has received an "INVITE dialog usage" request or response (for dialog establishment or target refresh) with a Recv-Info header listing the given Info Package. A UA MUST cease sending INFO requests for a given INFO package when the UA receives an "INVITE dialog usage" request or response (for dialog establishment or target refresh) that does not contain a Recv-Info header listing the given Info Package.
Sounds good to me.
Section 3.1 - "the target UA may not send form package P" s/form/from/ Section 3.1 - "... the other UA in the dial will assume the ..." s/dial/dialog/
Got it.
Section 3.1 - "server MAY terminate the session with a CANCEL or BYE" When the "server" is the UAS of the request, CANCEL is not appropriate, and BYE would not be appropriate if it is an initial INVITE. In this case, the request would need to be rejected. When the "server" is the UAC, I don't think CANCEL is appropriate since it is the far-end UA of a specific dialog that the UAC has an issue with, not all possible UAs in the case of an initial INVITE.
Whoops - clearly we are talking about the UAC in this case.
Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"?
In the real world, MAY = SHOULD. This would not add any value. The value of the wording here is to encourage more MUSTS :-)
Section 8 - Why is the separator between Info-package-name and Info-package-param a DOT? Shouldn't it be a SEMI? I don't think that Info-package-param is similar to event-template in 3265. Its more like event-param.
Hmmm. That is one for my co-authors. I would offer semicolon is the way to go.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
