Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Jun 2006 11:53:36 +0200

Hi,

I think the draft looks pretty good, but I still have comments. Now, since the draft proposes not to use multiple usages in the first place we can of course discuss whether all issues need to be solved. But, if we choose NOT to solve them, I think it still would be good to document that the issues exist.

FIRST, where is "secure flag" defined? I think it would be good to add a reference, because as far as I know it's not defined in RFC3261.

SECOND, chapter 1 says: "The pseudo-dialog behavior of REGISTER could be considered a third usage.  Fortunately, no existing implementations have attempted to mix a registration usage with any other usage."

I am not sure what implementations there are out there, but I think it's enough to say: "The pseudo-dialog behavior of REGISTER is not considered a third usage".

THIRD, chapter 3.1 says that a 200 response to BYE destroys an Invite usage. As far as the UAC is concerned, I think that ANY response will destroy the Invite usage.

FOURTH, chapter 3.2 says that a subscribe usage can be created by a NOTIFY request. Do we need to clarify that it is not any NOTIFY, but a NOTIFY associated with a SUBSCRIBE or REFER. Maybe it's obvious, but still...

FIFTH, chapter 1 says that a dialog can contain only one Invute dialog usage. But, as we agreed an Invite usage can not be created within an existing dialog (no matter what type of usages already exist within that dialog), i.e. an Invite dialog usage can ONLY be created when the dialog itself is created, and one dialog can ONLY contain one Invite dialog usage. So, I think we need text to clarify that. It may sound obvious, but to avoid questions on the list in the future...

SIXTH, chapter 4.1, for 3xx responses, I think that instead of talking about "our example" we should say that a 3xx reponses is condiered to affect all usages within the dialog. Now, I guess that means that, within a subscribe dialog usage, refresh SUBSCRIBE requests shall be sent towards the new remote destination - BUT NOTIFY requests may still come from the old remote destination, and I assume is supposed to accept those NOTIFY requests (?). I think we need to say that.

For some of the 4xx responses you also talk about "our example scenarios". I think we should be more generic, and not base our "normative" text on examples.

SEVENTH, chapter 4.2 talks about transaction timeouts. It is possible that the remote party is not aware that one side has destroyed a usage, e.g. due to a transaction timeout (the message never reached the remote party). Then, if the remote side still sends requests for that usage. I think it would be good to mention this, and maybe add some proposed behavior or the receiver (shall it send 481?). This "unsynchronization" may also occur if all entities does not understand a specific 4xx response, and some entities remove the usage but others don't.

EIGHTH, chapter 4.3 talks about the impact of an error response "Mid-dialog requests with unknown methods cannot be matched with a usage". Now, at one point I said that at some point there MAY be "known" messages which do belong to a usage, but the receiver does not know to which usage. If the sender of such message receives an error response I think the behvior should be the same: the

NINETH: At one point, I also asked whether we should define some kind of "usage identifier". That would solve some of the problems we've identified. In that case we could also define a new response code, and use that instead of 603 (chapter 4.6) when refusing a new usage (e.g. because the "maximum number of usages" have been reached).

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 27. kesäkuuta 2006 23:42
To: sipping; Robert Sparks
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt

Robert,

This is pretty much done I think.

Down to nits now:

In 1:

    Usages have state that is not shared in the dialog.  For example, a
    subscription has a duration.  Multiple subscriptions in the same
    dialog each have thier own duration.

True, but subscribe usages have more state than that. Also Event type and Event ID. (I guess the parameters on the event type are part of the
type.) So perhaps the above should say:

    Usages have state that is not shared in the dialog.  For example, a
    subscription has a duration, event type, and event id.  Multiple
    subscriptions in the same dialog each have thier own duration, event
    type, and event id.

In description of 603 handling: Is the implication different if the request declined is one that would terminate the usage? Or in that case must one just wait for the usage to expire?

	Thanks,
	Paul

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Wed, 28 Jun 2006 09:09:00 -0500

Thanks Christer -

inline

On Jun 28, 2006, at 4:53 AM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
> I think the draft looks pretty good, but I still have comments.  
> Now, since the draft proposes not to use multiple usages in the  
> first place we can of course discuss whether all issues need to be  
> solved. But, if we choose NOT to solve them, I think it still would  
> be good to document that the issues exist.
>
>
> FIRST, where is "secure flag" defined? I think it would be good to  
> add a reference, because as far as I know it's not defined in RFC3261.
I can add a reference - it's in 3261 at the
last paragraph of section 12 (before the header-line for 12.1:
    A dialog contains certain pieces of state needed for further message
    transmissions within the dialog.  This state consists of the dialog
    ID, a local sequence number (used to order requests from the UA to
    its peer), a remote sequence number (used to order requests from its
    peer to the UA), a local URI, a remote URI, remote target, a boolean

  --> flag called "secure", and a route set, which is an ordered list of

   URIs.  The route set is the list of servers that need to be traversed
    to send a request to the peer.  A dialog can also be in the "early"
    state, which occurs when it is created with a provisional response,
    and then transition to the "confirmed" state when a 2xx final
    response arrives.  For other responses, or if no response arrives at
    all on that dialog, the early dialog terminates.

>
>
> SECOND, chapter 1 says: "The pseudo-dialog behavior of REGISTER  
> could be considered a third usage.  Fortunately, no existing  
> implementations have attempted to mix a registration usage with any  
> other usage."
>
> I am not sure what implementations there are out there, but I think  
> it's enough to say: "The pseudo-dialog behavior of REGISTER is not  
> considered a third usage".
It's important to capture that there is no operational knowledge of  
mixing REGISTER with other things. How about this instead:
"The pseudo-dialog behavior of REGISTER is not a third usage. There  
are no known attempts to use REGISTER inside any other usage."

>
>
>
> THIRD, chapter 3.1 says that a 200 response to BYE destroys an  
> Invite usage. As far as the UAC is concerned, I think that ANY  
> response will destroy the Invite usage.
503, 420. Then there's the 401/7 rathole of infinite depth. I believe  
we want to leave this text as is.
>
>
>
> FOURTH, chapter 3.2 says that a subscribe usage can be created by a  
> NOTIFY request. Do we need to clarify that it is not any NOTIFY,  
> but a NOTIFY associated with a SUBSCRIBE or REFER. Maybe it's  
> obvious, but still...
>
Ok - that's an easy change.
>
>
> FIFTH, chapter 1 says that a dialog can contain only one Invute  
> dialog usage. But, as we agreed an Invite usage can not be created  
> within an existing dialog (no matter what type of usages already  
> exist within that dialog), i.e. an Invite dialog usage can ONLY be  
> created when the dialog itself is created, and one dialog can ONLY  
> contain one Invite dialog usage. So, I think we need text to  
> clarify that. It may sound obvious, but to avoid questions on the  
> list in the future...
IIRC, the text that talks about a dialog containing only one invite  
usage is exploring/explaining the situation we have now, where you  
_can_ send an INVITE inside a subscribe dialog.

>
>
>
> SIXTH, chapter 4.1, for 3xx responses, I think that instead of  
> talking about "our example" we should say that a 3xx reponses is  
> condiered to affect all usages within the dialog.
The text that's there now says exactly that: Redirection mid-dialog  
is not well understood in SIP,
       but whatever effect it has impacts the entire dialog and all of
       its usages equally.
The following sentence that ties it into the example doesn't weaken  
the statement.

> Now, I guess that means that, within a subscribe dialog usage,  
> refresh SUBSCRIBE requests shall be sent towards the new remote  
> destination - BUT NOTIFY requests may still come from the old  
> remote destination, and I assume is supposed to accept those NOTIFY  
> requests (?). I think we need to say that.
Not in this draft. Clarifying what 3xx inside a dialog means is one  
of the action points that will come out of this draft
(remember the next step will be to develop a work plan to make  
changes/clarifications to standards track documents to clear up some  
of the confusing points).

>
> For some of the 4xx responses you also talk about "our example  
> scenarios". I think we should be more generic, and not base our  
> "normative" text on examples.
Two revisions ago we went through and tried to make sure that we had  
general statements in place in every section. Tying it to the example  
is still important.
If you see a place remaining where it only talks in terms of the  
example, but doesn't describe the general case, point it out and  
we'll fix it.

>
>
>
> SEVENTH, chapter 4.2 talks about transaction timeouts. It is  
> possible that the remote party is not aware that one side has  
> destroyed a usage, e.g. due to a transaction timeout (the message  
> never reached the remote party). Then, if the remote side still  
> sends requests for that usage. I think it would be good to mention  
> this, and maybe add some proposed behavior or the receiver (shall  
> it send 481?). This "unsynchronization" may also occur if all  
> entities does not understand a specific 4xx response, and some  
> entities remove the usage but others don't.
I'm not seeing the potential for any confusion here. 3261/5 both  
cover issuing 481s in this situation explicitly.

>
>
>
> EIGHTH, chapter 4.3 talks about the impact of an error response  
> "Mid-dialog requests with unknown methods cannot be matched with a  
> usage". Now, at one point I said that at some point there MAY be  
> "known" messages which do belong to a usage, but the receiver does  
> not know to which usage. If the sender of such message receives an  
> error response I think the behvior should be the same: the
This got truncated?
>
>
>
> NINETH: At one point, I also asked whether we should define some  
> kind of "usage identifier". That would solve some of the problems  
> we've identified. In that case we could also define a new response  
> code, and use that instead of 603 (chapter 4.6) when refusing a new  
> usage (e.g. because the "maximum number of usages" have been reached).
A good conversation to have, but not one to capture in this document.
> True, but subscribe usages have more state than that. Also Event  
> type and Event ID. (I guess the parameters on the event type are  
> part of the
> In description of 603 handling: Is the implication different if the  
> request declined is one that would terminate the usage? Or in that  
> case must one just wait for the usage to expire?
>
> 	Thanks,
> 	Paul
>
> This list is for NEW development of the application of SIP Use sip- 
> [email-masked] for questions on current sip Use  
> [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jun 2006 14:09:40 -0400

> FIFTH, chapter 1 says that a dialog can contain only one Invute dialog usage. But, as we agreed an Invite usage can not be created within an existing dialog (no matter what type of usages already e…

Did we agree to that?

	Paul