Subject: [sipcore] Comment on draft-ietf-sipcore-refer-explicit-subscription-01

From: <[email-masked]>
Date: Sat, 14 Mar 2015 16:58:36 +0000

Hello,

I did a late review of draft-ietf-sipcore-refer-clarifications-03 and draft-ietf-sipcore-refer-explicit-subscription-01.
I'm fine with those drafts but I just have one comment on  draft-ietf-sipcore-refer-explicit-subscription-01 and I prefer to do it before its publication:

On this draft it is clearly stated for the 'explicitsub' option tag that  "The event server identified by the Refer-Events-At URI could receive
SUBSCRIBE requests"
In section 5.1 :
For the 'nosub' option tag, even if it is stated that "no explicit subscription will be forthcoming", there is no explicit statement such as : A UA sending a REFER with the 'nosub' option tag MUST NOT send a SUBSCRIBE request for that dialog.

Maybe you consider, this situation cannot appear as this UA will not receive the event server URI in the Refer-Event-At?

In that case, I think it would be good to have the following statements:

-       in section 5.2: If the UA receives a 2xx-class response, it will not contain a Refer-Events-At header field.
and

-       in section 5.3: An element that accepts a REFER request with 'nosub' in its Require header field MUST return a 200 response that MUST NOT contain a URI that could be used to subscribe to the refer event state associated with this REFER request.

It is also possible that I missed something already mentioned in the draft.
If not, I think a statement like that could reinforce the correct usage of the 'nosub' option tag.

Sorry about this very late comment.

Kind regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 19 Mar 2015 08:29:02 -0500

Hi Marianne -

You point to an interesting edge, and the explicit MUST NOT requirements 
you suggest are not in the current text.

I don't think they need to be.

If you look at "what breaks if someone does these things", I don't 
believe anything does.

An agent sending a REFER with the nosub tag is saying "You don't need to 
keep state to serve subscriptions from me".
If the recipient decides for whatever reason that it wants to keep that 
state anyhow, who is harmed? Nothing breaks.
If it returns a Refer-Events-At header and something subscribes to 
what's there, what harm comes from allowing the
subscription?

The important part was that the recipient knows its ok to _not_ keep 
that state, and not return a Refer-Events-At header.
We could add text saying MUST NOT include the header in this case, but 
what good would that do?

Now the case you point out where something tries to send a SUBSCRIBE 
without having the equivalent of a URI from a Refer-Events-At URI is one 
of those things where something's acting out of protocol, and it could 
happen before this extension. Really the only thing that could happen is 
that someone tries to send a SUBSCRIBE in dialog, or out of dialog to 
the AoR or current remote-target, or just guessing random URIs. We 
already have a MUST NOT covering in-dialog. The out-of-dialog cases are 
covered by the exception cases at 6665 (an event server not holding 
state matching the subscription will reject it). The risk of someone 
guessing a valid URI to subscribe to is discussed in the security 
considerations section.

So, again, it's an interesting edge, but I don't think we need to add 
requirements around it.

RjS

On 3/14/15 11:58 AM, [email-masked] wrote:
>
> Hello,
>
> I did a late review of draft-ietf-sipcore-refer-clarifications-03 and 
> draft-ietf-sipcore-refer-explicit-subscription-01.
>
> I’m fine with those drafts but I just have one comment on 
>  draft-ietf-sipcore-refer-explicit-subscription-01 and I prefer to do 
> it before its publication:
>
> On this draft it is clearly stated for the ‘explicitsub’ option tag 
> that  "The event server identified by the Refer-Events-At URI could 
> receive
>
> SUBSCRIBE requests"
>
> In section 5.1 :
>
> For the ‘nosub’ option tag, even if it is stated that “no explicit 
> subscription will be forthcoming”, there is no explicit statement such 
> as : A UA sending a REFER with the ‘nosub’ option tag MUST NOT send a 
> SUBSCRIBE request for that dialog.
>
> Maybe you consider, this situation cannot appear as this UA will not 
> receive the event server URI in the Refer-Event-At?
>
> -in section 5.2:If the UA receives a 2xx-class response, it will not 
> contain a Refer-Events-At header field.
>
> and
>
> -in section 5.3: An element that accepts a REFER request with ’nosub’ 
> in its Require header field MUST return a 200 response that MUST NOT 
> contain a URI that could be used to subscribe to the refer event state 
> associated with this REFER request.
>
> If not, I think a statement like that could reinforce the correct 
> usage of the ‘nosub’ option tag.
>