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

Good point. I think "notification dialog" sounds right. I'm trying to avoid the term "subscription"...

Sent from mobile, might be terse 

> On Apr 28, 2016, at 8:19 AM, Ben Campbell <ben@nostrum.com> wrote:
> 
>> On 28 Apr 2016, at 9:13, Peter Saint-Andre wrote:
>> 
>>> On 3/20/16 4:45 PM, Peter Saint-Andre wrote:
>>> A further thought...
>>> 
>>> On 09/28/2015 09:32 PM, Ben Campbell wrote:
>>>>> On 28 Sep 2015, at 21:39, Peter Saint-Andre - &yet wrote:
>>>>> 
>>>>> On 9/24/15 11:55 AM, Ben Campbell wrote:
>>> 
>>> <snip/>
>>> 
>>>>>>>> Also, how does this violate the SIP semantic?
>>>>>>> 
>>>>>>> There's a mismatch in the meaning of subscribe. Treating a SIP
>>>>>>> subscription as if it were long-lived means the gateway follows the
>>>>>>> XMPP subscription model, not the SIP subscription model. A gateway
>>>>>>> implementer needs to choose which model to honor, and if it chooses
>>>>>>> the XMPP model then it's not honoring the SIP model (and vice-versa).
>>>>>> 
>>>>>> I think this depends on the resolution to the previous comment, but I
>>>>>> would say that if the protoocl behavior expectations of the SIP
>>>>>> subscriber are met, the semantic has not been violated.
>>>>> 
>>>>> Maybe. :-)
>>>>> 
>>>>> It still seems to me that the gateway is enforcing one model or the
>>>>> other. Perhaps "violate" is a strong word in this context, though.
>>>> 
>>>> I think we may be reading too much into the "ephemeral" subscription
>>>> model, while still trying to think of an xmpp subscription and a SIP
>>>> subscription of modeling the same thing. Both XMPP and SIP have an
>>>> ephemeral component and a long-lived component. In XMPP, the
>>>> subscription is long lived, and the presence session is relatively
>>>> ephemeral. In SIP, the authorization policy, and the presence of an
>>>> entity on a contact list are long lived, and the subscription is ephemeral.
>>>> 
>>>> So if we think of an XMPP subscription as equivalent to SIP subscriber
>>>> authorization, and an XMPP presence session as equivalent to a SIP
>>>> subscription, I think we can avoid violence to the assumptions of either
>>>> side.
>>> 
>>> That too is helpful toward a better description of the mismatch in
>>> models.
>> 
>> I propose to add the following paragraph to the introduction:
>> 
>>   Although specifications for both SIP and XMPP use the term
>>   "subscription", the term is employed in different ways.  In SIP, a
>>   "subscription" is the mechanism whereby a subscriber requests
>>   presence notifications from the contact over a relatively short
>>   period of time, renewed as necessary to keep receiving presence
>>   notifications.  By contrast, in XMPP a "subscription" is essentially
>>   shorthand for a long-lived presence authorization.  To prevent
>>   confusion, this document uses the term "notification request" for
>>   SIP subscriptions and the term "presence authorization" for XMPP
>>   subscriptions.
> 
> Hi Peter,
> 
> I think this is on the right track. But I'm afraid SIP people might confuse "notification request" with "NOTIFY request", i.e. the NOTIFY message itself.
> 
> To put things is SIP terms, would "subscription dialog" or "notification dialog" work? (Or maybe just "dialog"?)
> 
>> Then modify the rest of the document accordingly.
>> 
>> I started making these changes last night and will post a revised I-D either today or tomorrow.
>> 
>> Peter
> 
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox