Re: draft-cridland-xmpp-session-00

On 10 June 2014 04:44, Curtis King <[email protected]> wrote:

>
> On Jun 9, 2014, at 9:54 AM, Dave Cridland <[email protected]> wrote:
>
> On 9 June 2014 17:36, Curtis King <[email protected]> wrote:
>
>> Instead of adding an redundant flag into the XMPP spec. Why doesn’t this
>> draft state the <optional/> flag explicit and give the session as an
>> example? Otherwise we will be adding <optional/> to more features than
>> session.
>>
>
> We've discussed, and rejected, this before, for example:
>
> http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html
> http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html
>
> I'm not averse to reopening the discussion, though I'll still argue
> against it. One or other of a generic <optional/> and <required/> will
> always be redundant, and multiple <required/> elements will often conflict.
>
> In any case, you'll note that <optional/> in this instance doesn't really
> mean "optional" so much as "redundant" - in fact, I think the name is an
> artifact of the discussion we had back then, though I can't find the thread
> that proposes it in this case. (But both M-Link and Prosody do this, so I
> assume it was discussed sometime).
>
>
> It was in the 3921bis draft then removed. BTW, we are about to remove it
> from M-Link because it isn’t covered in any RFC or XEP.
>
>
Right, this is an alternative way to solve that problem.


> This draft will require servers and client changes, you could accomplish
> the same goal by a pure informational draft pointing such features are
> optional. Then only certain clients need to change. Note: Good clients like
> Swift already ignore the session feature.
>
>
Then it's not a good client - the session feature, if advertised, is
mandatory. So if you remove the <optional/> marker from M-Link, every
conforming client has to negotiate it. You can't claim that if it's RFC
6121 only then it's exempt, because then certain servers won't work (I
think ejabberd is one that actually requires the <session/>, in line with
RFC 3921).

In an ideal world, we'd track down every client that requires the feature
to be advertised, unfortunately that means every client using Smack over a
certain age, which includes almost every Android client amongst others.


> If you think it is clearer using a flag lets use a descriptive flag name
> like, rfc3921-compatibility.
>

I'm just documenting the status quo as deployed.


>
> cheers,
>
> ck
>
>

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp