Re: WGLC on draft-ietf-sip-info-events

Sounds sensible.

On Mar 4, 2009, at 3:47 AM, Elwell, John wrote:

> 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

_______________________________________________
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