Re: [xmpp] <optional> and <required/>

[Waqas Hussain <[e-mail]>]

On Wed, Mar 16, 2011 at 6:39 AM, Peter Saint-Andre <[e-mail]> wrote:
> On 3/15/11 4:30 PM, Peter Saint-Andre wrote:
>> On 3/13/11 12:54 PM, Waqas Hussain wrote:
>>> On Wed, Mar 9, 2011 at 8:03 AM, Peter Saint-Andre <[e-mail]> wrote:
>>>> On 3/8/11 7:47 PM, Kim Alvefur wrote:
>>>>> Hi!
>>>>>
>>>>> Just to point out that these sections[1][2] seems to conflict with this
>>>>> tread[3]. Otherwise, how does it make sense for roster versioning to be
>>>>> required?
>>>>>
>>>>> [1]: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-22#section-4.9.3.23
>>>>> [2]: http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-20#section-2.6.1
>>>>> [3]: http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html
>>>>
>>>> There are two different topics here:
>>>>
>>>> 1. Whether any given feature is mandatory-to-negotiate or
>>>> voluntary-to-negotiate.
>>>>
>>>> 2. Whether to define a generalized mechanism for such signalling, which
>>>> would apply to all features.
>>>>
>>>> The mailing list post you've cited applies to #2. Section 2.6.1 of
>>>> 3921bis applies to #1.
>>>>
>>>> I see your point about the <unsupported-feature/> stream error: it might
>>>> not make much sense to define such an error condition if there is no
>>>> generalized mechanism for signalling that any given feature is
>>>> mandatory-to-negotiate...
>>>>
>>>> Peter
>>>>
>>>
>>> I think the <optional/> in 3921bis should go.
>>>
>>> 3921bis defines two stream features. Both are optional. One wants
>>> <optional/> inside, the other doesn't. I think this <optional/> is a
>>> leftover from when we tried having a generalized mechanism for
>>> required features, and the only purpose it serves in this instance is
>>> to add redundant inconsistency.
>>
>> You might be correct. I will look at this during AUTH48, i.e., right now.
>
> I've thought about this a bit more.
>
> I agree that the <optional/> element here (copied from XEP-0237) is an
> artifact of discussions ~12 months ago.
>
> I would also assert that the roster versioning stream feature is merely
> informative (as is true of the subscription pre-approval stream feature
> in section 3.4), and that it would never be mandatory-to-negotiate.
> Therefore I would prefer that we modify the text of Section 2.6.1 as
> follows:
>
>   If a server supports roster versioning, then it MUST advertise the
>   following stream feature during stream negotiation:
>
>      <ver xmlns='urn:xmpp:features:rosterver'/>
>
>   The roster versioning stream feature is merely informative and
>   therefore is never mandatory-to-negotiate.
>
> (The latter sentence is copied from Section 3.4.)
>
> Peter

Thanks, that's perfect.

--
Waqas Hussain