Subject: RE: [Simple] 200 vs. 202

From: [email-masked]
Date: Fri, 7 Dec 2001 10:16:34 -0600

> From: Christian Huitema [mailto:[email-masked]]
> 
> So, It seems that much boils down to the expectations of the 
> subscriber,
> and its ability to sort out the mess created by a forking proxy. Do we
> want to add a header line in SIP, such as:
> 
> 	Fork-with-me: Don't you dare
> 
> This would clearly tell proxies to not fork around...

On a more serious note, I often lament the absence of a
"Forking-Proxy-Require" header in the base spec.

But I guess it's too late to do anything about that.

/a

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 7 Dec 2001 11:35:02 -0500

There's a set of caller preferences to control forking. From
draft-ietf-caller-pref-04.txt:

        fork-feature: This feature indicates whether a proxy should fork
             a request, or proxy to only a single address. If the server
             is requested not to fork, the server SHOULD proxy the
             request to the "best" address (generally the one with the
             highest q value). The feature is ignored if "redirect" has
             been requested.

There's also:

       recurse-feature: This feature indicates whether a proxy server
             receiving a 300-class response should send requests to the
             addresses listed in the response (i.e., recurse), or
             forward the list of addresses upstream towards the caller.
             The feature is ignored if "redirect" has been requested.

        parallel-feature: For a forking proxy server, this feature
             indicates whether the caller would like the proxy server to
             proxy the request to all known addresses at once, or go
             through them sequentially, contacting the next address only
             after it has received a non-200 or non-600 final response
             for the previous one. The feature is ignored if "redirect"
             has been requested.

Dave.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, December 07, 2001 11:17 AM
> To: 'Christian Huitema'; Brazier Lachlan; Paul Kyzivat ; 
> Jonathan Rosenberg 
> Cc: [email-masked]; 'Brian Stucker' ; simple 
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> _______________________________________________
> simple mailing list
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
>

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 7 Dec 2001 08:10:15 -0800

So, It seems that much boils down to the expectations of the subscriber,
and its ability to sort out the mess created by a forking proxy. Do we
want to add a header line in SIP, such as:

-- Christian Huitema

> From: Brazier Lachlan [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 3:14 AM
> To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: [email-masked] '; ''Brian Stucker' '; 'simple '
> Subject: AW: [Simple] 200 vs. 202
> 
> Hello,
> 
> I believe the subscriber SHOULD keep all NOTIFY messages which arrive
> before
> the response to the SUBSCRIBE arives. After receiving the response the
> subscriber can decide which way to handle the NOTIFY's.
> 
> 1) Only accept NOTIFY's which fit to the response
> 
> 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?)
> 
> 3) Accept only a subset of the NOTIFY's (based on some local policy)
> 
> If the subscriber doesn't want to wait for the response to the
> SUBSCRIBE,
> and NOTIFY's arrive before the response, it has the possibilities:
> 
> 1) Accept the first NOTIFY and ignore the response
> 
> 2) Accept all NOTIFY's and ignore the response
> 
> 3) Accept only a subset of the NOTIFY's
> 
> 4) Accept no NOTIFY. When the response to the SUBSCRIBE arrives,
> subscribe
> again, but then accept the NOTIFY from the sender from the first
> SUBSCRIBE.
> ( NOTE: I DON'T propose that)
> 
> There was the proposal to accept the dialog which arrives first, be it
> response or NOTIFY.
> 
> 
> Did I forget another possibility? I think all of them work. Basically
> all of
> them depend on a kind of local policy and on the kind of application,
> which
> shouldn't be controlled anyway by the protocol.
> 
> So I vote for 1) as default procedure.
> 
> Lachlan
> 
> 
> -----Originalnachricht-----
> Von: Paul Kyzivat
> An: Jonathan Rosenberg
> Cc: [email-masked]; 'Brian Stucker'; simple
> Gesendet: 06.12.01 22:58
> Betreff: Re: [Simple] 200 vs. 202
> 
> [SNIP]
> 
> >
> > Do we have consensus though? I'd like to declare this issue
> resolved.
> Adam's
> > proposal was to accept the first NOTIFY, and ignore the 2xx. I'd
> like
> to
> > suggest a mild variant to that that I think is even simpler. My
> proposal is
> > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first,
> that
> > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes
> first,
> > you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE
> may
> or may
> > not be for the dialog that was accepted; it doesn't really matter.
> >
> > Agreement?
> 
> I don't have a preference between those two alternatives.
> 
> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing.
> 
> 	Paul
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> http://mailman.dynamicsoft.com/mailman/listinfo/simple