I believe that there is one open issue which we did not resolve during the
design team calls, mainly because I thought of it too late.
The approach to Appearance Acquisition using the Dialog Package Parameter
approach described in section 5 violates the semantics of NOTIFY and
PUBLISH. It
also requires that the resource acquisition request be performed in one
dialog,
while the response is received in another, which is rather strange.
Snipped from 11.2
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<------ NOTIFY F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
F1 is a request for an appearance; it might be a particular appearance, or
it
could be a request for any available appearance. The 200OK does not
indicate if
an appearance was acquired, or whic was acquired.
The appearance is returned in F5; which is a different dialog. This doesn't
match the 3265 NOTIFY semantics:
Notification: Notification is the act of a notifier sending a NOTIFY
message to a subscriber to inform the subscriber of the state of a
resource.
I have discussed this style of resource acquisition should be performed with
a few people; 3
approaches have been considered.
1. SUBSCRIBE with a body as a filter--new event package used to retrieve
appearances.
I had this as a straw man; after talking to Adam I'm convinced that this is
also
an abuse of 3265, if not as egregious.
2. BFCP - Rohan Mahy
You have a floor for each named appearance. If you want to sieze an
appearce
you request the floor for the next available appearance. If it fails you
try
the next one. The chance of one failure is small, the change of two
consequtive
failures is very, very low. BCFP is lightweight and fast. This approach
allows
a commodity dialog event server to be used if it has the appropriate
composition policy.
3. GRUU-REG thing from Dean Willis after 3 drinks
A separate registrar controls the appearances. Each appearance is a GRUU.
Appearances are requested using a REGISTER; a parameter specifies if a
specific
appearance is requested; otherwise the next available appearance is
returned.
-Derek
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
