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

["Ben Campbell" <[e-mail]>]

Hi Peter,

I'm catching up on some backlog. Is this version ready to go in your 
opinion, or was there more work to do?

Thanks!

Ben.

On 28 Apr 2016, at 13:47, Peter Saint-Andre wrote:

> I just submitted -08 to address this issue (and clean up some related 
> text and examples).
>
> On 4/28/16 10:00 AM, Peter Saint-Andre wrote:
>> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stox