Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 2 Mar 2009 11:48:07 +0100

(As WG cochair)

A reminder of the current WGLC on this document, which completes Wednesday.

Please submit your comments as soon as possible.

If you are reviewing the document, and you consider there may be a delay in your comments appearing, then please send a mail to the chairs so they can ascertain whether more time is needed.

regards

Keith 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Monday, February 16, 2009 7:08 PM
> To: SIP IETF
> Cc: Eric Burger; DRAGE, Keith (Keith)
> Subject: WGLC on draft-ietf-sip-info-events
> 
> 
> I'd like to request the SIP Working Group perform final 
> review on the INFO Events draft:
> 
> 
> http://tools.ietf.org/id/draft-ietf-sip-info-events-03.txt
> 
> 
> 
> Please review this draft and bring any issues to the mailing 
> list, copying the author.  Please conclude this review 
> process by March 4, 2009.
> 
> --
> Dean Willis
> cp-Chair, SIP WG
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 2 Mar 2009 05:18:37 -0800

> If you are reviewing the document, and you consider there may be a delay
> in your comments appearing, then please send a mail to the chairs so they
> can ascertain whether more time is needed.

I haven't received a reply concerning my February 16 (archived on 17) email: "draft-ietf-sip-info-events-03: comments and questions".  Thus I'm not sure if I will have follow-up comments based upon the reply.

http://www.ietf.org/mail-archive/web/sip/current/msg26621.html

The following is a snapshot of my questions and comments in case the authors did not see my prior email.

Thanks,
Brett

----

Section 3.1 paragraph 1:  Concerning "MUST advertise" and "provisional 1xx", please clarify that the "MUST advertise" is not applicable to the 100 response.  Does the "MUST advertise" and "provisional 1xx" apply to all (first and subsequent within dialog) INVITE non 101-199 (intentionally indicated 199)?  Concerning ACK for initial INVITE's 2xx, does the "MUST advertise" always apply?

Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 indicates "session parameters" and sentence 2 indicates "dialog parameters" concerning Info Package negotiation, I'm not sure when the negotiation/renegotiation occurs.  Does it follow SDP offer/answer rules or something else; if something else, what?  I have the same question concerning "dialog refresh" text discussed later within the same section since incorrect interpretations might trigger deactivation.

Section 4.3: When sending a 489, it indicates "MUST terminate the INVITE dialog".  The "MUST terminate" seems severe even if all the negotiation race conditions are adequately addressed.  The mentioned "protocol failure" reason seems contrary to the "strictly send and lenient receive" mantra.

Section 5.1 Table 1: The usage of "g" seems potentially outdated or incorrectly reference since discussed within RFC 2543 instead of RFC 3261.  The same applies to usage Via row concerning "(2)".

Section 5.2.2: The "general-header" reference is outdated or incorrectly reference since defined within RFC 2543 instead of RFC 3261.  RFC 3261 uses "Message-Header".

Section 7.7 paragraph 2: The following potentially could be reworded since it is okay to return failure responses (401, 503, 500, ...) even when overlapping occurs: "in the event a UAC issues overlapping INFO requests for an Info Package, the UAS MUST NOT return an error response".

Section 8: Why specifically defining and using "nil"?  I'm mainly just curious of the benefit over not having defined "nil" for similar use within the Supported header.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 3 Mar 2009 15:59:40 +0100

Frequently the editor's wait until the end of the WGLC before processing the comments, so I am sure that it has not been forgotten.

It does have the advantage of making sure that we do not swap and change when we get conflicting comments.

regards

Keith 

> From: Brett Tate [mailto:[email-masked]] 
> Sent: Monday, March 02, 2009 1:19 PM
> To: DRAGE, Keith (Keith); SIP IETF
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: WGLC on draft-ietf-sip-info-events
> 
> > If you are reviewing the document, and you consider there may be a 
> > delay in your comments appearing, then please send a mail to the 
> > chairs so they can ascertain whether more time is needed.
> 
> I haven't received a reply concerning my February 16 
> (archived on 17) email: "draft-ietf-sip-info-events-03: 
> comments and questions".  Thus I'm not sure if I will have 
> follow-up comments based upon the reply.
> 
> The following is a snapshot of my questions and comments in 
> case the authors did not see my prior email.
> 
> Thanks,
> Brett
> 
> ----
> 
> Section 3.1 paragraph 1:  Concerning "MUST advertise" and 
> "provisional 1xx", please clarify that the "MUST advertise" 
> is not applicable to the 100 response.  Does the "MUST 
> advertise" and "provisional 1xx" apply to all (first and 
> subsequent within dialog) INVITE non 101-199 (intentionally 
> indicated 199)?  Concerning ACK for initial INVITE's 2xx, 
> does the "MUST advertise" always apply?
> 
> Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 
> indicates "session parameters" and sentence 2 indicates 
> "dialog parameters" concerning Info Package negotiation, I'm 
> not sure when the negotiation/renegotiation occurs.  Does it 
> follow SDP offer/answer rules or something else; if something 
> else, what?  I have the same question concerning "dialog 
> refresh" text discussed later within the same section since 
> incorrect interpretations might trigger deactivation.
> 
> Section 4.3: When sending a 489, it indicates "MUST terminate 
> the INVITE dialog".  The "MUST terminate" seems severe even 
> if all the negotiation race conditions are adequately 
> addressed.  The mentioned "protocol failure" reason seems 
> contrary to the "strictly send and lenient receive" mantra.
> 
> Section 5.1 Table 1: The usage of "g" seems potentially 
> outdated or incorrectly reference since discussed within RFC 
> 2543 instead of RFC 3261.  The same applies to usage Via row 
> concerning "(2)".
> 
> Section 5.2.2: The "general-header" reference is outdated or 
> incorrectly reference since defined within RFC 2543 instead 
> of RFC 3261.  RFC 3261 uses "Message-Header".
> 
> Section 7.7 paragraph 2: The following potentially could be 
> reworded since it is okay to return failure responses (401, 
> 503, 500, ...) even when overlapping occurs: "in the event a 
> UAC issues overlapping INFO requests for an Info Package, the 
> UAS MUST NOT return an error response".
> 
> Section 8: Why specifically defining and using "nil"?  I'm 
> mainly just curious of the benefit over not having defined 
> "nil" for similar use within the Supported header.
> 
>

---

From: Bob Penfield <[email-masked]>
Date: Tue, 3 Mar 2009 12:11:46 -0500

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.

---

From: Eric Burger <[email-masked]>
Date: Tue, 3 Mar 2009 15:10:33 -0800

It absolutely has not been forgotten: I was hoping to get more  
comments, but I'll get back with comments to the comments by the end  
of the week.

Thanks for your read of the document!

On Mar 3, 2009, at 6:59 AM, DRAGE, Keith (Keith) wrote:

> Frequently the editor's wait until the end of the WGLC before  
> processing the comments, so I am sure that it has not been forgotten.
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Mar 2009 08:47:15 +0000

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Penfield
> Sent: 03 March 2009 17:12
> Subject: Re: [Sip] WGLC on draft-ietf-sip-info-events
> 
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 6 Mar 2009 17:03:06 -0500

Inline.

> not indicate what packages it can send.

Correct.  Editing shrapnel. It is really in Section 1 (this is a note  
for me).

> that also might need to be changed.

How about "Info Package Behavior"?

>   Recv-Info header listing the given Info Package.

Sounds good to me.

> Section 3.1 - "... the other UA in the dial will assume the ..."
Got it.

>  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 :-)

> Info-package-param is similar to event-template in 3265. Its more like

Hmmm. That is one for my co-authors.  I would offer semicolon is the  
way to go.

---

From: Eric Burger <[email-masked]>
Date: Fri, 6 Mar 2009 17:03:53 -0500

Sounds sensible.