Re: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05

[Saúl Ibarra Corretgé <[e-mail]>]

Sorry for coming late folks, looks like you got almost everything sorted out :-)

>> 
>>>>> -2nd paragraph after example 11:
>>>>> This also needs a NOTIFY. You mention one in the following paragraph for
>>>>> the declined case, but you need one in either case.
>>>> 
>>>> Yes. The XMPP server will generate a presence notification in this
>>>> case, so that's the primary NOTIFY of interest here, I think.
>>> 
>>> I think it's still worth mentioning that it happens. And that brings up
>>> another question: A RFC 6665 notifier is required to send an "immediate"
>>> NOTIFY. Do you think the presence stanza will reliably arrive at the
>>> gateway in time to be considered "immediate"? If there's any likelihood
>>> of delay, the gateway may need to send a "pending" NOTIFY.
>> 
>> Not sure. I'll think about that some more.
> 
> It might be reasonable to punt this to the implementation to decide, with some guidance about what to do if you can't immediately send a "real" NOTIFY. And on reflection, this gets tangled up with authorization--the "pending" NOTIFY is more to say the authorization has not yet been determined. If the subscriber is known to be authorized, then rather than a "pending" NOTIFY it might just send a normal NOTIFY with some default presence state, then send the real presence when it gets it. (The subscriber's user experience might be a to initially see the entity as "closed" then quickly transition to "open”.

You could still send an empty NOTIFY with subscription state “active”, to indicate that the it has been allowed by the policy, but there is no presence state to show at this moment. How to interpret that is of course implementation specific.


--
Saúl Ibarra Corretgé
AG Projects