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

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

On 25 May 2016, at 15:03, Peter Saint-Andre wrote:

> Yes, I think it's ready to go. I can give it a once-over consistency 
> check first if you'd like, though.

Only if you think it needs it. Otherwise I will dive in shortly.

Thanks!

Ben.

>
> Thanks!
>
> Peter
>
> On 5/25/16 1:55 PM, Ben Campbell wrote:
>> 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