[Standards] Dealing with the choice to have a different MIX roster format

Dave Cridland dave at cridland.net
Thu Jun 15 20:59:50 UTC 2017


On 15 Jun 2017 20:44, "Steve Kille" <steve.kille at isode.com> wrote:



> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Sam
> Whited
> Sent: 15 June 2017 20:20
> To: XMPP Standards
> Subject: Re: [Standards] Dealing with the choice to have a different MIX
> roster format
>
> On Thu, Jun 15, 2017 at 10:38 AM, Florian Schmaus <flo at geekplace.eu>
> wrote:
> > You misunderstood.
> >
> > The point here is that a <mix xmlns='urn:xmpp:mix:1'/> element as
> > child of <query xmlns='jabber:iq:roster'/>, is different than <mix
> > xmlns='urn:xmpp:mix:1'/> as child element of <message
> > xmlns='jabber:client'/>.
>
> Only by convention or as part of the application logic; as far as a
parser is
> concerned those are "the same thing".
>
> > I can't remember when something like that has ever caused problems, or
> > how I could cause problems in this particular case.
>
> I think it doesn't cause problems because we normally don't do that.
> An example of somewhere else that we do that would be useful if it exists,
> otherwise I suspect it's just confusing and should probably be avoided.
>
> —Sam

[Steve Kille]

Thanks Sam.

This element is NOT going to be called <mix/>.

I'm happy to call it something other than <mix-info-request/> although I
think this is a fine choice


Just to join in the bike shed, <roster xmlns="urn:xmpp:mix:roster:0"/>, and
place the item marker in the same namespace. In both cases, it feels as if
these ought to stabilize quickly, and we may as well take advantage of this.



Steve


_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: Standards-unsubscribe at xmpp.org
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170615/37af8f39/attachment-0001.html>


More information about the Standards mailing list