Subject: RE: [Sipping] Re: Update: dialogusage

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Mar 2006 14:02:53 +0100

Hi,

Some comments on the -01 revision.

General:

Q1: The forking issue (see separate thread) also has to be covered, but
since that was brought up after the -01 revision had been released it is
understandable it's not there at the moment.

Chapter 4.1:

Q2 (Editorial): In chapter 4.1, I think we could simplify by saying that
"the Retry-After does not affect other usages". I don't think we need to
describe what Retry-After means - RFC3261 does that.

Q3: I agree with Paul on the 481 issue. As I said earlier, I think we
shall be consistant.

Chapter 4.4:

Q4: You say that a target refresh is updated when a 200 OK is
sent/received for the target refresh request. What if I use reliable 18x
responses for a target refresh re-INVITE request? Do I send the PRACK
according to the old target? In order to avoid yet another
can-I-send-18x-responses-to-a-reINVITE-request discussion I would
propose that we somehow change the wording to something that also covers
reliable 18x responses.

Chapter 4.6:

Q5: Could this draft also propose, or at least mention the possibility
of, a new response code?

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 4. maaliskuuta 2006 2:34
To: Robert Sparks
Cc: sipping WG; Christer Holmberg (JO/LMF)
Subject: [Sipping] Re: Update: dialogusage

Robert,

I am really liking this now. (I am still not too wild about the
preaching, but it is to a level I can tolerate and I know I am in the
minority.)

I did find some things - mostly minor, except for one below where I used
CAPITAL LETTERS.

I have used quoted text for excepts from the draft that I am referring
to.

	Thanks for this,
	Paul

Section 1 - list of shared state: also the "secure flag".

Section 3.1 - is invite usage destroyed by the response to the BYE, or
by the BYE? Is anybody going to keep their dialog because the BYE was
rejected?

>    429 Provide Referrer Identity: This response won't be returned to a
>       NOTIFY as in our example scenario, but when it is returned to a
>       REFER, it is objecting to the REFER request itself, not any
usage
>       the REFER occurs within.  The usage is unaffected.  Any other
>       usages sharing this dialog are unaffected.  The dialog is only
>       affected by a change in its local CSeq.

nit picking. Since REFER is a usage-establishing request, I don't think
it should be considered to be within any existing usage.

>    480 Temporarily Unavailable: RFC 3261 is unclear on what this
>       response means for mid-usage requests.  Clarifications will be
>       made to show that this response affects only the usage in which
>       the request occurs.  No other usages are affected.  If the
>       response included a Retry-After header field, further requests
in
>       that usage should not be sent until the indicated time has past.
>       Requests in other usages may still be sent at any time.

This might occur for a usage-establishing request not in an existing
usage. In that case further requests should probably not be sent that
attempt the same kind of usage. But this might only mean not subscribing
to the same event package - subscribing to some other event package
might be ok. Very fuzzy. (Even out of dialog it is fuzzy.)

>    500 and 5xx unrecognized responses: These responses are complaints
>       against the request (transaction), not the usage.  If the
response
>       contains a Retry-After header field value, the server thinks the
>       condition is temporary and the request can be retried after the
>       indicated interval.  This usage, and any other usages sharing
the
>       dialog are unaffected.  If the response does not contain a
Retry-
>       After header field value, the UA may decide to retry after an
>       interval of its choosing or attempt to gracefully terminate the
>       usage.  Whether or not to terminate other usages depends on the
>       application.  If the UA receives a 500 (or unrecognized 5xx) in
>       response to an attempt to gracefully terminate this usage, it
can
>       treat this usage as terminated.  If this is the last usage
sharing
>       the dialog, the dialog is also terminated.

A large part of the above text appears to be applicable to many of the
4nn responses.

>    MESSAGE requests are not currently allowed inside a dialog (though
>    some implementations use it that way, against the standard
>    recommendation).  As it is not meant to be part of any given
dialog,
>    it cannot be part of any given usage.  A failed MESSAGE request
>    should have similar effects on a dialog and its usages as a failed
>    OPTIONS request.

The restriction is more nuanced than that. From 3428:

    The authors recognize that there may be valid reasons to send
MESSAGE
    requests in the context of a dialog.  For example, one participant
in
    a voice session may wish to send an IM to another participant, and
    associate that IM with the session.  But implementations SHOULD NOT
    create dialogs for the primary purpose of associating MESSAGE
    requests with one another.

Section 4.5:

>    Abnormal termination can effect all usages on a dialog.  Rejecting
a
>    NOTIFY with a 481 (incorrectly recommended in the past as an
>    inexpensive way to terminate a REFER subscription) destroys the
>    dialog and all of its usages.

THIS IS REALLY WRONG NOW - inconsistent with earlier language.

Robert Sparks wrote:
> I've just submitted
> http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.txt
> http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.htm
> l
> 
>  From the changelog section:
> 
> A.1.  draft-ietf-00->draft-ietf-01
> 
>    o  Changed 481 to only affect the usage the response occured in,
>       closing the last open issue.  Added some text justifying this
>       recommendation.
>    o  Added 422 Session Interval Too Small
>    o  Added 417 Uknown Resource-Priority
>    o  Added 428 Use Identity Header
>    o  Added 436 Bad Identity-Info
>    o  Added 437 Unsupported Certificate
>    o  Added 438 Invalid Identity header
>    o  Added a section categorizing messages that create and destroy
>       usages
>    o  Made sure all descriptions in Section 4 addressed the generic
>       multi-usage case.
>    o  Clarified that the mechanics described in matching messages to
>       usages applied equally to UACs and UASs.
>    o  More explicitly noted that REFER creates a subscribe-usage
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Mar 2006 14:48:29 -0500

> propose that we somehow change the wording to something that also covers

I don't recall at the moment how clear things are that the target 
refresh takes effect at the 200. Logically I think it has to be this 
way, because it would make little sense to have the target refresh take 
effect on a reliable 1xx and then have the request fail.

Does everyone agree this is the way it must be?

	Paul