Re: draft-cridland-xmpp-session-00
Ralph Meijer <[email protected]> Tue, 10 Jun 2014 10:26:25 +0200
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
On 2014-06-10 10:07, Kevin Smith wrote: > On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland <[email protected]> wrote: >>> 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. > > Yeah, I don't believe this is true. Swift treats the session start as > unnecessary, but if it's offered by the server it'll negotiate it. The > relevant code is splattered around > http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp Oh, but it is. RFC 3921 says, section 3 says: Upon being so informed that session establishment is required [*] (and after completing resource binding), the client MUST establish a session [..] [*] The part above that shows the stream feature being advertised, and because of that wording I believe it implies that advertising Session Establishment makes it required. Then RFC 6121 only mentions that the protocol is unnecessary (Appendix E), but doesn't explicitly make it optional when advertised. I.e. it doesn't change the protocol, just doesn't document it any more. >> So if you remove the <optional/> marker from M-Link, every >> conforming client has to negotiate it. > > Every 3920/1 client, that is, rather than every 6120/1 client. yes? I think you will find there are no pure forms of either, in reality. >> 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). > > Right. Clients still need to implement this for old servers (I assume > modern ejabberd /doesn't/ require this, but very old versions are > undoubtedly out in the wild). I disagree. Clients only need to implement this if they want to benefit from the removal of a roundtrip with servers advertising this flag. > I think the draft is roughly the right thing to do. Nits: > > od->of > > <optional/> really isn't what this really is. Is there scope for > naming it <obsolete/>? How widely deployed are clients-servers that > use optional and are unlikely to be upgradable? I'm uncomfortable with > standardising that <optional/> means MUST NOT. As I said before, adding this flag makes the client *choose* to not negotiate Session Establishment, therefore making it optional. I don't really care for renaming this with existing implementations (like your own) already having this deployed in the field. I don't think it does anyone a favour, except protocol purists. I do agree <optional/> should mean 'SHOULD NOT negotiate'. > If we have to do this, we should probably add some text that > <optional/> is only used in the context of session startup. I'm not sure what you mean here. To be sure, this flag is only being defined for this namespace / stream feature. -- ralphm