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

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

Any thoughts?

On 9 Jun 2016, at 17:37, Ben Campbell wrote:

> Hi Peter,
>
>
> I have a couple of questions about the implications of the new 
> "presence authorization" concept, and a couple of editorial nits. 
> Otherwise, I think this is ready for IETF last call. It might make 
> sense to go ahead with the last call, and address these with any last 
> call comments--but I'd like to have an initial round of conversation 
> about the presence authorization first.
>
> - in 5.2.3, whose "authorization" is canceled? If the SIP contact has 
> a reciprocal subscription back to the xmpp contact’s presence, is 
> that impacted by this unsubscribe action? Or is the SIP user expected 
> to remove the authorization for the xmpp user to see her presence 
> info?
>
> - in 5.3.1, I _think_ the flow creates both an authorization and a 
> notification dialog. If the SIP user unsubscribes, and resubscribes 
> (that is, tears down the notification dialog and creates a new one), 
> is there any difference in the flow due to the fact the XMPP server 
> has authorization state for the SIP user? (Would F29 and F30 still 
> happen?)
>
>
> Nits:
>
> - 1, 5th paragraph: s/specfic/specific/
>
> - 5.2.2, first paragraph, last sentence: I suspect "whenever" should 
> be "... sufficiently in advance of when..."
>
>
>
>
>
>
>
>
> 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.
>>
>> 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
>>
>> _______________________________________________
>> stox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stox
>
> _______________________________________________
> stox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stox