jdev - 2020-02-23

  1. Жокир

    Is there a single client or server that is known to include cdata sections in its xml streams?

  2. Sam Whited

    Not that I've ever seen. That would likely make it incompatible with most everything else

  3. Жокир

    Do clients and servers generally support namespace prefixes other than the usual "stream" referring to "http://etherx.jabber.org/streams"? I mean, sending the whole namespace url every time seems kind of silly and also wastes traffic. One good example would be "<r xmlns='urn:xmpp:sm:3'/>". The namespace url is longer than the actual message. With prefixes it could be shortened to e.g. "<s:r/>"

  4. jonas’

    Жокир, no.

  5. jonas’

    last I tried that, things broke terribly

  6. jonas’

    it’s also a SHOULD NOT in RFC 6120, if I recall correctly

  7. jonas’

    ah, slightly different

  8. jonas’

    from 4.8.5, RFC 6120 <https://tools.ietf.org/html/rfc6120#section-4.8.5>: > Interoperability Note: For historical reasons, an implementation MAY accept only the prefix 'stream' for the stream namespace (resulting in prefixed names such as <stream:stream> and <stream: features>); this specification retains that allowance from [RFC3920] for the purpose of backward compatibility. Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems. If an entity receives a stream header with a stream namespace prefix it does not accept, it MUST close the stream with a stream error, which SHOULD be <bad-namespace-prefix/> (Section, although some existing implementations send <bad-format/> (Section instead.

  9. jonas’

    so you might face implementations which close your stream with <bad-namespace-prefix/> if you do that, however, I found that they may not do that and instead misbehave

  10. flow

    jonas’, that section seems to talk only about the stream namespace prefix, not about additional namespace prefixes.

  11. jonas’


  12. jonas’


  13. jonas’

    wrong section

  14. flow

    Жокир, I'd also expect that to be fragile, but we could add add a stream feature indicating support for this

  15. jonas’

    I’m pretty sure that there was wording which discouraged or forbid usage of stream-level prefixes inside stanzas. And I’m also pretty sure that there was wording which discouraged use of stream-level prefixes altogether.

  16. jonas’

    but I can’t find either

  17. jonas’

    nevertheless, in practice, I’ve had issues with declaring namespace prefixes anywhere

  18. pep.

    https://xmpp.org/extensions/xep-0044.html flow

  19. jonas’

    you’ve got my attention

  20. pep.

    jonas’ too.

  21. jonas’

    > An implementation will need to maintain some sort of mapping between prefixes and namespaces, though some parsers, such as recent versions of Expat, can do this for the implementor.

  22. jonas’

    oh my god, those must’ve been grim times

  23. jonas’

    I’ll ask council to give me authorship of that thing

  24. jonas’

    I want to clean it up and give it a stream feature and bring it to Draft

  25. pep.

    \o/ our saviour

  26. pep.

    is stream features enough? would that be so that you start a new stream knowing about it?

  27. pep.

    or continue in the same stream with it?

  28. MattJ

    TIL about XEP-0044

  29. jonas’

    pep., a client could abort the stream if the server doesn’t advertise it

  30. jonas’

    *declaring* namespace prefixes on <stream:stream/> has typically not been an issue, but using them leads to fun behaviour

  31. pep.


  32. flow

    I even think there is no need to abort the stream/connection: implementations could just fallback to the default behavior and pretend that they never declared the namespace prefixes

  33. flow

    and kudos to pep for digging out xep44 :)

  34. lovetox

    it does not matter how long you are in this community, there is always one more XEP you didnt know about

  35. jonas’

    flow, more annoying to implement though ;)

  36. flow

    jonas’, actually I was just thinking about how to do it in smack, and at least here I don't think it would be that of an issue. The XML serialize already has knowledege about an xml environment which also holds the active namespace prefixes, so it's just a matter of zapping those again, if the server does not announce support for them

  37. jonas’

    flow, in aioxmpp, it’d be a compile-time constant effectively. or a lot more code and slowness to include an optional "normaliser" at the serialisation level

  38. jonas’

    hm, ok, zapping those is an interesting approach

  39. pep.

    flow, fwiw larma told me about it

  40. pep.

    credits where it's due

  41. pep.


  42. flow

    pep., deleting them again from the xml environment

  43. flow

    like they where never added in the first place

  44. jonas’

    that should actually work without much overhead

  45. pep.

    If you intend to "zap" these namespaces then it means you have some kind of check in place to see if they're being used. So you'd have to check as long as your program runs. If you then zap them, you'd have to check that they're being zapped first

  46. flow

    pep., I am confused, but I also think that this is not the case. Take Жокир example with SM: assume the SM namespace has been declared as prefix in <stream/>, if now the server does not support it, smack will just fallback to do what it already does

  47. flow

    if the support announces support for it, then the serialize will emit <sm:r/>

  48. flow

    if the support announces support for it, then the serializer will emit <sm:r/>

  49. pep.

    Emitting is fine yes, I'm talking about reading

  50. flow

    ahh reading is a good point, a stream feature may not be enough in the c2s case, clients may want to tell the server that they support this

  51. pep.

    When receiving a stanza, if it's possible to have both, then I have to try both

  52. flow

    but in reading the situation is similar

  53. jonas’

    pep., no, you don’t have to "try"

  54. flow

    pep., what is "both" here?

  55. jonas’

    it’s unambiguous which serialisation variant is used and your XML parser will deal with it (if it supports it) and blow up otherwise

  56. flow

    actually a full prefix aware parser should not blow up if you redundantly state the namespaces again

  57. pep.

    jonas’, ah wait, for some reason I had in mind that the namespaces themselves would change. Let me redo the maths with this info

  58. flow

    anyhow, I think there is maybe a reason why we do not see widespread adoption of xep44: may parsers do not carry around the full context of the document

  59. pep.

    flow, yeah and maybe they should :x

  60. flow

    Android XmlPullParser doesn't, and I wouldn't be suprised if Java's stax parser doesn't do also

  61. jonas’

    is there no namespace-compliant parser in android? O_o

  62. jonas’

    i.e. a thing which always gives you (namespace, local_name) instead of a qname?

  63. flow

    I always read a qname as a namespace and a localpart (localname)

  64. flow

    No the issue is that the parser would give you the localpart and the prefix

  65. jonas’

    qname is prefix:localname, at least in my glossary

  66. jonas’


  67. jonas’

    I hate those paresrs

  68. jonas’

    we should all burn them

  69. flow

    well I read qname as the thing that fully qualifies the name, so either a local-name and a namespace, or the triple of local-name, prefix, and the prefix-matching namespace

  70. jonas’

    right, so, let me clarify:

  71. flow

    anyhow, if the prefix is not declared within the same element, you may not get the namespace with some parsers

  72. jonas’

    parsers which do not expose (namespace, local-name) tuples hassle-free everywhere and instead give you prefix+local-name shall burn in hell

  73. jonas’

    the fuck what

  74. jonas’


  75. pep.

    yeah there's no reason the application sees prefixes, it doesn't need them. Now that's a bit more complex because of us not doing 0044 already but..

  76. jonas’

    pep., actually, you need prefixes in some XML applications such as SOAP

  77. moparisthebest

    Json doesn't have namespaces therefore nothing needs them ever, if you are following along

  78. flow

    jonas’, interesting, why do you *need* them?

  79. pep.

    Well you also need them in XMPP. If 0044 had been a thing from the start we wouldn't have. If people had fully supported namespaces we wouldn't have needed them.

  80. jonas’

    flow, because they use prefixes in character data :(

  81. flow

    jonas’, interesting, why do you *need* them in SOAP?

  82. pep.

    Now we do, because we'll need to pass the info down to the XML parser at runtime

  83. jonas’

    pep., incorrect, RFC 6120 ties the usage of namespaces down enough to not need them

  84. jonas’

    you don’t need to know that the `stream:` prefix is used; the namespace is authoritative.

  85. jonas’

    but you should use the `stream:` prefix for compat reasons

  86. moparisthebest

    But yea I've dealt with various XML impls in Java that all seem to handle namespaces differently, or not at all, it's a bit of a nightmare

  87. pep.

    Right so in a way you do

  88. jonas’

    pep., why?

  89. pep.

    What you just said, compat

  90. jonas’

    just for the initial declaration

  91. jonas’

    but that’s not for parsing, but for serialisation

  92. pep.

    Sure, that still means the application knows

  93. jonas’

    yeah, that’s true

  94. jonas’

    I was specifically talking about parsing though

  95. pep.


  96. jonas’

    serialisation is different, because you normally *want* to pass information about prefixes to the serialiser

  97. jonas’

    the application knows better than the serialiser about which namespaces should be declared

  98. jonas’

    (e.g. declaring the stream-management namespace on the stream:stream element, a serialiser can never guess that you’ll use that namespace often)

  99. jonas’

    since declaring namespace prefixes is essentially an optimisation (unless you do namespaced attributes, where they’re required)

  100. flow

    FYI, moparisthebest, stax appears to be fine

  101. flow

    moparisthebest, http://paste.debian.net/1131699/

  102. moparisthebest

    flow: https://github.com/moparisthebest/sxf4j 2012 looks like the last time I tried it, I think maybe half of those backends are unmaintained now...

  103. flow

    moparisthebest, yeah, I think StAX's introduction in Java 8 helped here a lot

  104. flow

    which was ~2014

  105. moparisthebest

    This was with java6 too, seems like the dark ages now :)

  106. jonas’

    it sure sounds like dark ages

  107. flow

    So for Smack, I am probably going to support XPP3 for the next for years. Ideally the Android Platform would then provide the StAX API (after google moved a bit $$$ towards oracle potentially). Otherwhise one has to bundle another xml parser library for Smack on Android if I ever drop support for XPP3

  108. flow

    So for Smack, I am probably going to support XPP3 for the next few years. Ideally the Android Platform would then provide the StAX API (after google moved a bit $$$ towards oracle potentially). Otherwhise one has to bundle another xml parser library for Smack on Android if I ever drop support for XPP3

  109. flow

    I also could introduce namespace awareness in Smack's XPP3 compatiblity layer, hmmm

  110. Жокир

    There isn't a single xep involving ns prefixes with attributes, is there? Can this xml feature be safely ignored then?