Subject: [Simple] Re: draft-levin-simple-interdomain-reqs-02

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2005 16:09:53 -0500

Orit,

There are lots of things in this draft that might be worthy of 
discussion. There are a few things that I especially want to bring up:

5.3.1 Ensuring User Validity

    "An edge proxy MAY automatically periodically generate re-SUBSCRIBEs
     towards an external SIP/SIMPLE community..."

Proxies aren't allowed to initiate new requests this way. The 
resubscribes need to come from the watcher. I don't know what you 
intended here.

    "In the absence of any bilateral agreement
     between the administrative authorities for each community,
     subscriptions to the same URI MUST NOT occur more frequently than
     every two hours."

That would be really inconvenient if the expiration time on the 
subscription was less than two hours. Seems like it would be better to 
suggest that subscriptions not be gratuitously refreshed more frequently 
than implied by the expiration time of the subscription. I say 
"gratuitously" because there are other valid reasons to resubscribe:
- to change parameters (e.g. filters)
- to get a full state snapshot when synchronization has been lost
   with partial notification state

6.3.2 MESSAGE inside INVITE Session

1) I am somewhat concerned about publishing a document thru the ietf 
recommending use of MESSAGE inside of an INVITE dialog. I am 
*especially* concerned about blessing the use of "m=message 5060 sip 
<SIP URI>". AFAIK the latter is not a valid m-line for SDP.

2) Regarding: "The recipient's UA MUST ignore all INFO messages ... that 
it doesn't understand."

I'm not sure what you mean by "doesn't understand". I presume you mean 
that the body isn't understood, since headers that aren't understood are 
always to be ignored. That would perhaps make sense if 
content-disposition handling parameter is set to "optional" and if the 
recipient supports the INFO method at all. But it is contrary to 3261 to 
require support of INFO or the ignoring of required but ununderstood 
body parts.

	Thanks,
	Paul

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Edwin Aoki <[email-masked]>
Date: Fri, 11 Mar 2005 16:09:50 -0800

Paul,

On behalf of Orit, Avashalom, and myself, thanks again for your
comments.  I'm working with Orit to update this document for its next 
go-round and had a question about one of your comments.

Paul Kyzivat wrote:

> ...
> suggest that subscriptions not be gratuitously refreshed more 
> frequently than implied by the expiration time of the subscription. I 
> say "gratuitously" because there are other valid reasons to resubscribe:
You make a good point about the need to allow re-SUBSCRIBEs in certain
cases, generally having to do with situations in which the watcher needs
to indicate some change to the presentity's PA (including the indication
that it needs a refresh of full presence state), but I have a concern
about your suggestion to modify the text to not allow subscriptions to
be refreshed more frequently than that implied by the expiration time,
rather than some hard limit (e.g. 2 hours).

As you point out, the intent behind this section was to prevent
gratuitous re-SUBSCRIBEs, but the text you propose would not prevent a
watcher in one community from issuing an initial SUBSCRIBE request to a
presentity in another community with a very short expiration and then
refreshing it continuously.  I understand the reluctance to dictate a
hard minimum, but without some lower bound on this operation, the impact
on traffic across the interdomain link could be quite large.

We could potentially use something akin to Aki's throttling proposal to
allow this to be negotiated, I suppose, but I don't know if that adds
more complexity than is strictly necessary.

-Edwin Aoki
-Chief Architect
-America Oniline, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Mar 2005 22:04:53 -0500

Edwin - comments inline.

	Paul

> on traffic across the interdomain link could be quite large.

Yes, I see how that could be a problem. However, 3265 has a provision to 
deal with that:

    The notifier MAY also check that the duration in the "Expires" header
    is not too small.  If and only if the expiration interval is greater
    than zero AND smaller than one hour AND less than a notifier-
    configured minimum, the notifier MAY return a "423 Interval too
    small" error which contains a "Min-Expires" header field.  The "Min-
    Expires" header field is described in SIP [1].

Of course the interval is one hour rather than two. But That doesn't 
seem so awful. (I am guessing that the value of two hours that you use 
was an arbitary one.)

The only thing that doesn't deal with is a notifier that forces a 
subscription to have too small a value. That seems somewhat far fatched. 
If you feel it is a plausible problem, then you could consider proposing 
a revision to 3265 allowing a Min-Expires header in a SUBSCRIBE request.