[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt
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:pkyzivat at cisco.com]
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-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP