On 14 August 2014 21:14, Kurt Zeilenga <[email protected]> wrote:
> > On Aug 14, 2014, at 1:03 PM, Dave Cridland <[email protected]> wrote: > > On 14 August 2014 20:57, Kurt Zeilenga <[email protected]> wrote: > >> >> On Aug 14, 2014, at 12:33 PM, Dave Cridland <[email protected]> wrote: >> >> On 14 August 2014 18:12, Kurt Zeilenga <[email protected]> wrote: >> >>> While XEP 298 does say: >>> >>> 1. >>> >>> The namespace of the forwarded stanza MUST be preserved (this is >>> typically 'jabber:client'). If no 'xmlns' is set for the stanza then as >>> per >>> XML namespacing rules it would inherit the 'urn:xmpp:forward:0' >>> namespace, >>> which is wrong. >>> >>> This, by itself, is insufficient to ensure all relevant namespaces of >>> the original stanza are preserved. Any namespaces of the stream which the >>> original message was received on, as well those of the original stanza need >>> to preserved if used in the original stanza, need to preserved. Also, >>> lang tags should preserved. >>> >>> >> I agree that we need to ensure that all relevant namespaces are >> preserved. I'm in general agreement about xml:lang, but I'd note that >> servers should really be preserving this on routing anyway, and don't. >> >> >> Because it's a PITA. :-) >> >> > Sure. But why is it suddenly important here? > > > Because I happen to be working on both xml:lang support in a server > including in messaging archiving. > > Sure - I'm happy that xml:lang might be preserved properly. > > >> >> >>> One way to do this is for the forwarded to copy all the name space >>> declarations of the stream the original message was received into the >>> forward element, use a prefix for the 'urn:xmpp:forward:0' which >>> doesn't clash, and copy all prefixes of the original message with the >>> original message, using the same prefixes as on the stream it was received >>> on. >>> >> >> This seems rather ham-handed, and also restricted to implementations >> which are aware of the prefixes used, and the namespaces declared. I also >> don't think it's ever needed. >> >> >> First, I think we need to separate the general requirements on namespace >> and language preservation from a suggestion of how on might implement said >> requirement. >> >> >> >> >>> >>> So, for instance, if one received: >>> >>> <stream:stream >>> from='[email protected]' >>> to='im.example.com' >>> version='1.0' >>> xml:lang='en' >>> xmlns='jabber:client' >>> xmlns:stream='http://etherx.jabber.org/streams'> >>> <message> >>> <body>foo</body> >>> </message> >>> </stream:stream> >>> >>> >>> >>> The element to be forwarded (inside a suitable message element) would be: >>> >>> <forwarded:forwarded xmlns:forwarded='urn:xmpp:forward:0 >>> xml:lang='en' >>> >>> xmlns='jabber:client' >>> xmlns:stream='http://etherx.jabber.org/streams'> >>> >>> <message> >>> <body>foo</body> >>> </message> >>> >>> </forwarded:forwarded> >>> >>> >> Including the stream namespace here seems of no value. >> >> >> Depends on whether the stream namespace is used anywhere in the original >> stanza. While one could examine the original stanza to determine if the >> namespace is used, my suggested approach was written under the assumption >> that the implementation is far more likely to blindly copy all or portions >> of the original element into the <forwarded/> element without such >> examination. Many implementations avoid going "deep" into stanzas. >> >> > Is the stream namespace even possible to use within a stanza? I can't > think of a case where it might be. > > > Possible? We're talking XML! > > Which is the problem, the content of a <message/> is unrestricted. If > someone wants to re-use some item of stream schema in their extension, they > can. To say they cannot, well, would be really odd from an XML perspective. > > Well, you could embed a stream in entirety inside a stanza, but... why? Seems like this is optimizing for a case that doesn't exist. > > >> >> If an implementation has declared other namespaces at the stream level - >> and I vaguely recall some Blackberry client doing this - then the client is >> wrong - RFC 6120 $4.8.5, last paragraph. >> >> >> My suggestion was based on the fact that namespace for the stanza could >> be in the stream element or in the stanza element. >> >> > The content namespace might be in either just the stream header, or the > stanza too, but it's always the default namespace, which means it's trivial > to locate. > > > >> >>> Or if one received: >>> >>> <stream >>> from='[email protected]' >>> to='im.example.com' >>> version='1.0' >>> xml:lang='en' >>> xmlns='http://etherx.jabber.org/streams'> >>> <message xmlns='jabber:client'> >>> <body>foo</body> >>> </message> >>> </stream> >>> >>> >>> <forwarded:forwarded xmlns:forwarded='urn:xmpp:forward:0'xml:lang='en' >>> >>> xml:lang='en' >>> >>> xmlns='http://etherx.jabber.org/streams'> >>> >>> <message xmlns='jabber:client'> >>> <body>foo</body> >>> </message> >>> >>> </forwarded:forwarded> >>> >>> >>> >> No, the content namespace MUST be without prefix, and MUST be declared as >> such in the stream header, so this is invalid too. >> >> >> Note here that I'm providing a forwarded element that is to placed inside >> a <message/> element. And per paragraph you just referenced, belong in >> stanza not the stream header. Or maybe I'm confused as to what you are >> complaining about here. >> > > The stream open MUST contain the content namespace, which MUST be the > default namespace. The stream open given in this example is invalid, since > it doesn't declare a content namespace (or, depending how you squit, does, > but it's an invalid one). > > > That example is straight from RFC 6120, section 4.8.2. I think you miss > the "Alternatively" to the MUST you quote. > Oh, poo. Yes, you're quite right. I keep on forgetting we allowed that one. Dave.
