On 6 January 2012 04:30, Nobuo Ogashiwa <ogash...@c.kyoai.ac.jp> wrote: > Dear Matthew, >
> However, how can I support the other server which will send initial > stream header > without the 'version' attribute (or with the version='0.9') and > require the features stanza. > I didn't see such server for now but I think it meets the requirements > of current RFC and XEP so > there is a possibility of such server would appear in the future. > It doesn't meet the requirements. There are two versions of the protocol, the "old" one (0.9) and the new one (1.0). 1.0 was the first official XMPP standard. Before 1.0, there were no stream:features. A server that does not support version='1.0' and requires <stream:features> would just be silly. > According to the XEP-220, >> Although this method of advertising protocol support has been superseded by >> the use of stream features as originally defined in RFC 3920, the server >> dialback >> protocol predates the existence of stream features and therefore the >> namespace >> declaration method is still used in this instance. > > Is this imply " if 'version=0.9' then MUST NOT send features stanza, > if 'version=1.0' or higher then MUST send features stanza" ? No, XEP-0220 is not talking about sending <stream:features>, it is talking about advertising dialback support *inside* <stream:features>. Obviously you would only send <stream:features> on a 1.0 stream, but XEP-0220 is just telling you that you should also support the old method of advertising dialback support (xmlns:db) too. > If such rules or restriction is not yet clearly described in any RFCs or XEPs, > I think it should be clearly described in RFC or XEP for future developers. Your worry is a server that uses a protocol version <1.0, but also requires <stream:features> (a >=1.0 feature). Even if such a server exists, why should it suddenly be updated just because a new RFC/XEP is published? If it isn't updated to 1.0, I don't see why it would be updated to anything else. If you ever do find such a server, first file a bug report against it, and second... let me know :) Regards, Matthew _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
