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

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.

_______________________________________________
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