I agree with Bob that the use of UAC and UAS terminology is confusing. I cite some particular examples below.
1. In 3 it defines the two terms, but early in 3.1 it states "The initiating UA (UAC of the INVITE)", which uses "UAC" in a sense different from what is defined. 2. "the UAC MUST NOT send INFO requests for a given Info Package until the UAS lists the given Info Package in a Recv-Info header." According to the definition of UAC, a UAC is the sender of an INFO request. So while waiting to receive Recv-Info it is not a UAC. Similarly, the other end is not a UAS by virtue of sending "Recv-Info" - it only becomes a UAS when it receives an INFO request. Don't forget that a UA is a UAC or a UAS only in the context of a particular transaction, and before that transaction takes place and after that transaction has finished it is just a UA. Any attempt to change the meaning of UAC or UAS would be a departure from RFC 3261. 3. "A UAS lists multiple packages by enumerating the package name(s), separated by commas, as values for the Recv-Info header in the session establishment exchange. A UAS can also list multiple packages by including multiple Recv-Info headers...." We are talking about sending Recv-Info - nothing to do with an INFO transaction, so the term UAS is inappropriate. 4. "This initial dialog establishment phase is the only time the UAS need be prepared to receive multiple INFO requests, as we require post-session-establishment negotiation to fully complete before a UAC can send an INFO request." followed shortly afterwards by: "A UAC MAY send an INFO request on both an early and confirmed dialog." Either these are conflicting statements or there is some mix-up of terms UAC and UAS. 5. In "Conventions Used in this Document" it states: "Since this document strictly follows RFC 3261, we refer to the UA that issues the INVITE as the "initiating UA" and the UA that responds to the INVITE as the "target UA" to remove any confusion." I don't think this is good practice, and I would even say that by doing this we no longer strictly follow RFC 3261 terminology. If it is clear we are talking about an INVITE transaction we should be free to use UAC and UAS. So in general, where it is clear which transaction we are talking about (e.g., because it has appeared earlier in the paragraph concerned), we should just use UAC or UAS. Otherwise we should use expressions like "the UAC for the XXX transaction" or "the UA that sends the XXX request". John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bob Penfield > Sent: 03 March 2009 17:12 > To: DRAGE, Keith (Keith); SIP IETF > Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events > > > 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. > > 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. > > 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. > > 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/ > > 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. > > Section 7 - Can Info Packages strengthen "MAY" to "SHOULD"? > > 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. > _______________________________________________ > 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 > _______________________________________________ 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
