Subject: [sipcore] INFO draft

From: Eric Burger <[email-masked]>
Date: Thu, 16 Jul 2009 19:08:41 -0400

The silence is deafening. Please +1 or -1, as the WGLC is underway. If  
you're too tired of the topic, just +1 to prove you read the email.

http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 17:34:39 -0700

+2

On Jul16 2009 16:08 , "Eric Burger" <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 16 Jul 2009 23:51:11 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eric Burger
> Sent: Thursday, July 16, 2009 7:09 PM
> To: SIPCORE
> Subject: [sipcore] INFO draft
> 

+1 (but I didn't read the email)

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Fri, 17 Jul 2009 08:56:09 -0400

I finally read the new draft, and I do have some comments.

1) In Section 3.2 (UAC Behavior) it says:

    If the UAS does not send any Recv-Info headers in a message, then the
    list of supported Info Packages does not change.

  But then it says:

    A UAC MUST cease sending INFO requests for a given INFO package when
    the UAC receives an "INVITE dialog usage" request or response (for
    session establishment or target refresh) that does not contain a
    Recv-Info header listing the given Info Package. 

  This implies that the UAC must stop sending INFO requests for a given
  package if there are no Recv-Info headers in a received request or
  response. Suggest the following:

    A UAC MUST cease sending INFO requests for a given INFO package when
    the UAC receives an "INVITE dialog usage" request or response (for
    session establishment or target refresh) that contains a
    Recv-Info header that does not list the given Info Package. 

2) Section 3.2 should mention that a 469 response does not destroy the
INVITE dialog usage. If the application determines that the dialog
usage cannot continue due to the 469 response, it should send a BYE to
terminate the dialog usage.

3) The example in 10.1 does not include the mandatory Content-Disposition
header.

cheers,
(-:bob

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Jul 2009 09:07:11 -0400

+1
Yes, I remember and mostly understood the discussion of the issue.
Yes, I have actually read the draft, and it does a good job of 
addressing the issue.
Let's get it done.
Joel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jul 2009 14:02:53 +0100

+1 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Eric Burger
> Sent: 17 July 2009 00:09
> To: SIPCORE

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jul 2009 15:21:37 -0400

Eric,

This doc is in better shape than most others at this stage.
I did find some things, though mostly nits at this point.
A couple rise above the nit level.

Section 1:

>    This draft addresses these deficiencies and provides a
>    framework for explicit negotiation of capabilities and content
>    context using "Info Packages".

I thought this was considered to be an "advertisement", not a "negotiation".

Section 3.1:

>    Recall the UAC of an INVITE may choose to receive (be a UAS for) INFO
>    methods.  This UA may chose not to offer any packages in the initial
>    INVITE and subsequently advertise packages from the target UA's
>    subsequent responses, in order to support third-party call control
>    [RFC3725].

Not sure this is adequate. There is no way for a UA to indicate what it 
wishes to send, and sending/receiving are not symmetric. So announcing 
you will receive what the other end will receive doesn't make sense.

But waiting for a subsequent message before indicating what you will 
receive can make sense in some cases.

Section 3.4:

>    This means the initiating UA is willing to receive from Info Packages
>    P and R.

>    This indicates the target UA is willing to receive from Info Packages
>    R and T.

>    The target UA can now send from package R to the initiating UA.
>    Moreover, in this example, the target UA may not send from package P,
>    as P no longer is in the initiating UA's Info Package set.

The phrasing is odd. I would recommend changing "from [Info] package" to 
"[Info] package".

The example in this section also leaves me scratching my head a bit. 
While the actions and the implications all seem "correct", the 
plausibility of the case seems a bit suspect. I don't know if it is 
intended to be plausible, or just "possible" to make the example.

Specifically, I'm thinking there is an *implication* that Alice removed 
P from the ACK because it hadn't been mentioned by Bob in the response. 
If that is intended, then I don't understand *why* there would be such a 
causal relationship between those two things. At best it would only make 
sense due to some special properties of the P and R package semantics.

Section 4.1:

>    That Info Package token MUST match one of the Info Packages the UAS
>    indicated support for during the negotiation described in Section 3.

There is that "negotiation" word again!

>    A UAC MUST NOT use the INFO method outside an INVITE dialog usage.
>    The INFO method has no lifetime or usage of its own, as it is
>    inexorably linked to that of the INVITE.  When the INVITE-created
>    session terminates, that signals the termination of the negotiated
>    Info Packages.  A UAS that receives an INFO message after the INVITE
>    dialog usage terminates MUST respond with a 481 Call Does Not Exist.

This seems to apply to legacy usage as well (as it should). But perhaps 
it is not clear enough. I have encountered problems with that. I would 
recommend being very explicit that this applies to legacy usage, and was 
the intent of 2976 as well.

>    The session identifiers defined in RFC 3261 [RFC3261] must match
>    those of the provisional or final responses to the INVITE.  As a
>    result, INFO requests cannot fork.  The UAC may send INFO requests
>    once the UAS has sent the Recv-Info header field value, indicating
>    what the UAS supports.
> 
>    The converse is not true during initial session establishment.  The
>    initiating UA of the first INVITE MUST be prepared to receive
>    multiple INFO requests, as the first INVITE may fork.  Since session
>    negotiation has not completed, and we allow early INFO requests,
>    multiple target UAs may respond.  This initial session establishment
>    phase is the only time the UAS need be prepared to receive multiple
>    INFO requests, as one would expect there may be messages from non-
>    authoritative forked dialogs prior to their termination.

The point of the above is good, but the wording is problematic to me.
Specifically "The converse" bothers me because it isn't the converse of 
anything.

The point is that even though a given INFO cannot fork, an INVITE *can* 
fork, and the Initiating UAC must be prepared to receive INFO on any and 
all resulting INVITE dialog usages, whether early or final. How about 
the following for the second paragraph above:

    However, because an initial INVITE may fork, the
    initiating UA of the first INVITE MUST be prepared to receive
    INFO requests on any and all dialogs, early and confirmed,
    that result.

Section 4.2:

>    If the Info Package definition directs the UAC to send a request
>    without a payload, the UAC MUST send the INFO request without a body.

The above partially contradicts the next paragraph. So, I suggest 
replacing above with:

    If the Info Package definition directs the UAC to send a request
    without a payload and nothing else about the message requires a
    body part, the UAC MUST send the INFO request without a body.

(I left the last requirement at MUST strength, but I wonder if it ought 
to be that strong.)

It would also probably read better if this were moved down just before:

>    If there is no payload for the Info Package, they UAC MAY omit the
>    Content-Disposition header.

Regarding the following:

>       NOTE: We could be lazy and even save 33 octets by allowing the UAC
>       to construct a non-multipart MIME payload without a Content-
>       Disposition header.  However, mandating the presence makes parsing
>       considerably easier, and it is easier to have it required now than
>       run into a problem later.

I guess this would be defining a per-request-type default for C-D.
AFAIK we don't have that now, though we do have per-content-type C-D 
defaults. The more of that we do the more complex the rules become for 
inferring the right thing. And we also have the issue of legacy use of 
INFO, which futher complicates things.

So I agree its better to require this.

Section 4.3:

>    If a UAS receives an INFO request, it MUST send a final response.  A
>    UAS MUST send a 200 OK response for an INFO request with no message
>    body and no Info-Package header if the UAS received the INFO request
>    on an existing session.  This protocol action supports legacy use of
>    INFO as a keep-alive mechanism.

I know this is trying to preserve legacy behavior. But the MUST is still 
a bit strong. In particular, it must still be possible to reject the 
message for cause. In particular, the UAS must be able to send a 401 
response if it is requiring per-message authentication and the necessary 
info is missing or wrong. And it must be able to send a 500 response if 
the CSeq is too small. And there are probably other cases where error 
responses are appropriate. So how about:

    If a UAS receives an INFO request, it MUST send a final response. A
    UAS MUST send a 200 OK response for an INFO request with no message
    body and no Info-Package header if there is no non-INFO-specific
    reason to reject the message.  This protocol action supports legacy
    use of INFO as a keep-alive mechanism.

Or maybe this can be better related to the last paragraph in this 
section, which does address the sending of such errors. Currently it 
isn't clear that paragraph applies to this case.

>    If the UAS receives an INFO request with an Info-Package the UAS
>    advertised with a Recv-Info in the last session state update and the
>    body of the INFO request is an appropriate MIME type for the Info
>    Package, the UAS MUST send a 200 OK response.

I think it would be useful to add a note clarifying this:

    NOTE: Errors in info-package-specific or application-specific
    processing of the Info Package, other than MIME type conformance,
    are not to result in a failure response.

> 4.5.  Behavior of Registrars
> 
>    Registrars receiving a REGISTER request that includes Recv-Info
>    headers MAY store such information and use it for routing purposes.
>    How the registrar uses this information is beyond the scope of this
>    document.

Hmm. I don't recall this. Maybe I've just forgotten. It seems a bit 
mysterious and unmotivated. Without some normative behavior, it seems 
useless.

AFAIK there are no comparable statements for other headers that might be 
equally interesting for routing purposes.

If you want the possibility of having the capability to route based on 
the ability to receive particular info packages, then we should probably 
add a new callee-capability that could be used for this purpose.

Section 7.5:

>    The UAS MUST enumerate every MIME type associated with the Info
>    Packages advertised in the UAS' Recv-Info header the UAS is willing
>    to receive.  If a UAC sends a body that includes something not
>    enumerated by the UAS, this is a protocol error and the UAS MUST
>    respond appropriately.

I'm really confused here by the use of UAC and UAS (vs. Initiating UA 
and Target UA, and generally what this is about. Enumerate *where*?

Is this saying that the message containing Recv-Info must also include 
an Accept header enumerating the content-types associated with the 
packages it lists? If so, must it accept *all* the content-types 
associated with a package? Or if the package supports alternative 
content types, can it simply accept a subset that works for the package?

Section 8:

>    extension-method    = INFOm / token

This is supposed to be updating 3261, so I think this is supposed to be:

    extension-method    /= INFOm / token

>    Info-package-param  =  token

name=value not allowed for params???

s/token/generic-param/

Section 9.5:

>    Please add the following registration to the Content-Disposition
>    registry.  The description suitable for the IANA registry is as
>    follows.
> 
>    The payload of the message carrying this Content-Disposition header
>    field value is the payload of an Info Package.

The above is missing the "following registration" giving the name of the 
C-D being defined.

Section A.2:

>    Some uses of INFO can tolerate this fate sharing of the INFO message
>    over the entire session.  For example, in the SIP-T usage, it may be
>    acceptable for a call to fail, or to tear down the call, if one
>    cannot deliver the associated SS7 information.  The same is usually
>    true for DTMF.  However, it may not be acceptable for a call to fail
>    if, for example, a DTMF buffer overflows.  Then again, for some
>    services, that may be the exact desired behavior.

This is another case where all the words are true, but the implication 
is not. Specifically, if the DTMF buffer were to overflow, that would be 
an application level issue. It would not cause the INFO message carrying 
it to fail, and so would not cause the INVITE-usage to fail.

Section A.3:

>    There is no throttling mechanism for INFO.  Consider that most call
>    signaling occurs on the order of 7-10 messages per 3 minutes,
>    although with a burst of 5-7 messages in one second during call
>    setup.  DTMF tones occur in bursts at a rate of up to 20 messages per
>    second.  This is a considerably higher rate than for call signaling.
>    Sending constant GPS location updates, on the other hand, would incur
>    an undue burden on SIP Proxies along the path.

*Which* other hand is being referenced? (There seem to be two other 
hands.) How about:

    Sending constant GPS location updates would place
    an even larger burden on SIP Proxies along the path.

Section A.4:

>    path.  In fact, SIUBSCRIBE/NOTIFY is your only option if you need to
>    exchange data outside a communications session.

This is a little overreaching. Perhaps:

    path.  In fact, SIUBSCRIBE/NOTIFY is your only SIP signaling path
    option if you need to exchange data outside a communications session.

Of course you subsequently mention MESSAGE, which is another exception.

Section A.5.4:

Maybe I'm mising something, but the content of this section seems in 
direct conflict with the mechanism defined in this draft. Its like this 
section is left over from a year or two ago before we decided to go with 
info packages. What am I not getting?

That's it. I could find nothing else.

	Thanks!!!
	Paul

---

From: Xavier Marjou <[email-masked]>
Date: Thu, 30 Jul 2009 17:59:41 +0200

Sorry for this late answer:
+1

2 additional minor comments:

1/
Replace
   "A UAC conforming to this document can always send or receive
legacy INFO usages without packages."
By
   "A UA conforming to this document can always send or receive legacy
INFO usages without packages."
Indeed, RFC3261 indicates that the UAC is the entity that sends SIP
requests, the UAS the one that receive SIP responses. An UA can do
both.

2/
Similarly it also written some lines later that:
 "A UAC MAY send a legacy INFO [RFC2976] method at any time."
I would suggest to replace it by
 "A UA MAY send or receive a legacy INFO [RFC2976] method at any time".
 (I have not understood your explanation in your previous response in
another mail indicating why such replacement was not possible).

Cheers,
Xavier

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 30 Jul 2009 12:01:49 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Xavier Marjou
Sent: Thursday, July 30, 2009 12:00 PM
To: Eric Burger
Cc: SIPCORE
Subject: Re: [sipcore] INFO draft

1/
Replace

2/

Cheers,
Xavier

> you're too tired of the topic, just +1 to prove you read the email.
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.tx
t