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

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

Hi, 

>>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.

[CHH] Ok, I found it. I guess the usage of it may depend on the SIPS discussion we're having, but that's a separate issue...

>>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."

[CHH] Sounds good.

>>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.

[CHH] Ok, I agree :)

>>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.

[CHH] Ok. But, in that case I think we need to clarify that the INVITE shall not be regarded as a re-INVITE, because it WILL contain a To tag.

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

[CHH] Fair enough. But, should we then document those action points somehow, so we don't forget about them?

>>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.

[CHH] I guess it's ok. I don't like the idea of having different behaviour for different types of response codes within the same "group" (4xx, 5xx or 6xx), but I understand it would be difficult to come up with something more generic.

>>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?

[CHH] Yes. Sorry for that. What I meant to say was: If the sender of such message receives an error response I think the behavior should be the same as for unknown methods which cannot be matched with a usage. Ie if the sender receives an error response for a method (known OR unknown) which the receiver may not match to a specific usage, it should not terminate the usage. I don't think we have such known methods today, though.

>>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.

[CHH] An action point?

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 sip- 
> [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: Wed, 28 Jun 2006 18:34:04 -0400

> [CHH] Ok. But, in that case I think we need to clarify that the INVITE shall not be regarded as a re-INVITE, because it WILL contain a To tag.

Yeah, I suppose so. Its really just like SUBSCRIBE refreshes: its a 
refresh because there is a matching usage. If no matching usage then it 
is a usage-establishing request. Its actually a little simpler for 
INVITE because there is at most one invite-usage per dialog.

	Paul