Subject: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-00

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Jan 2015 12:26:30 +0000

Hi,

Some comments on draft-ietf-sipcore-refer-explicit-subscription-00:

-----------

Q1 (General):

Is there a reason why we need to limit the mechanism to INVITE-established dialogs?

(I do agree that, today, there are probably no other dialog types in which we would send REFER.)

-----------

Q2 (General):

Assume a UA sends an INVITE without including "NOTIFY" in the Allow header field. The UA does, however, include "REFER".

Assuming that the scope of Allow is for the given dialog (there is a separate thread on the scope of Allow), doesn't that mean that the UA, while it will accept REFERs, will not create implicit subscriptions within the dialog?

Would we need to say something about that?

-----------

Q3 (General)

The draft talks about mandating support and usage of the mechanisms by inserting the associated option-tags in the REFER Require header field.

But, the draft doesn't talk about the dialog creating request (i.e. the INVITE).

I think it would be good to say that the mechanism can be used even if the INVITE-sender did not indicate support (using the Supported header field).

(Otherwise we can only use the mechanism when the INVITE-sender also supports it, which reduces the applicability very much.)

-----------

Q4 (Section 3.1):

The text says:

	"If the recipient of the REFER accepts the request, it will begin
              managing the 'refer' event state described in RFC 3515, and will
              provide a URI that will reach an event server that will service
              subscriptions to that state."

Assuming that the subscription-event state terminates already when the REFER response is sent, is there really a need for the REFER-receiver to return a URI? 

Perhaps we could say that NOT providing a URI (or, providing a URI with a "null" value) means that the associated subscription-event state is terminated.

Of course, the REFER-sender could have included "Require: nosub" in the REFER request - IF it would have known that there will be no need for a subscription. But, it may not always know.

-----------

Q5 (Section 4.3 and/or 4.6):

Would it be good to explicitly clarify that the REFER-receiver, if accepting usage of the mechanism and providing a subscription-URI pointing to itself, MUST NOT send a NOTIFY until it has received the associated SUBSCRIBE?

It may be obvious to the SIPCORE participants, but I think it would be a good clarification for unexperienced readers :)

-----------

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Jan 2015 13:07:06 -0600

> Some comments on draft-ietf-sipcore-refer-explicit-subscription-00:
No, and the existing language wasn't intended to create that limit - 
instead it was pointing out the applicability to INVITE-established dialogs.
I'll change the wording in the next version to make it clear that this 
applies to dialog reuse in general.

No, I don't think so. Let's leave that discussion to something that 
normatively refines the definition of Allow.

In that context, we can talk about whether you draw the conclusion you 
suggest. (I don't think you can - Allow says "you can send me this 
method", so listing REFER, but not NOTIFY, does not say anything about 
whether the UA will or will not _generate_ NOTIFY requests.)

Again, I don't think this document is the place to talk about such things.
I'm confused about what's motivating your Otherwise. RFC3261 in no way 
restricts the use of Require to only talk about things that have 
previously been signaled as Supported?

I don't have a problem reminding the reader that it's ok to do so. (But 
only with plain prose - not with requirements language since that would 
repeat requirements from 3261.
No, I don't think this attempt at an optimization is a good idea. There 
can (and usually should) be more information in that final NOTIFY than 
just the fact that the subscription event state is terminated. To 
optimize out the conduit for providing that NOTIFY, you'd have to build 
a way to carry all the information it might have contained.
I can call this out, but someone would have to invent a lot to get this 
wrong. Where would they send that NOTIFY _to_? We've already said we're 
not sending as part of the association the REFER occurred on.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Jan 2015 07:47:13 +0000

Hi,

Q1 (General):

> No, and the existing language wasn't intended to create that limit - instead it was pointing out the applicability to INVITE-established dialogs.
> I'll change the wording in the next version to make it clear that this applies to dialog reuse in general.

Thanks.

 -----------

> Again, I don't think this document is the place to talk about such things.

Fair enough.

-----------

Q3 (General)

> repeat requirements from 3261.

It could be a short note.

(I got this question from some implementers, so for that reason I think it would be useful to clarify it.)

-----------

> a way to carry all the information it might have contained.

Fair enough.

(I did have a use-case in mind, but after some further thinking I think "Require: nosub" can be used for that.)

-----------

> not sending as part of the association the REFER occurred on.

After further thinking, I agree with you, and I don't think we need to say anything. So, I withdraw my comment.

(The important thing is that, if the REFER-receiver accepts the mechanism, a NOTIFY is not sent based on the REFER, but the text already says that.)

Regards,

Christer