[Standards] XEP 297 xmlns and lang preservation in forwarding

Dave Cridland dave at cridland.net
Thu Aug 14 20:40:04 UTC 2014


On 14 August 2014 21:14, Kurt Zeilenga <kurt.zeilenga at isode.com> wrote:

>
> On Aug 14, 2014, at 1:03 PM, Dave Cridland <dave at cridland.net> wrote:
>
> On 14 August 2014 20:57, Kurt Zeilenga <kurt.zeilenga at isode.com> wrote:
>
>>
>> On Aug 14, 2014, at 12:33 PM, Dave Cridland <dave at cridland.net> wrote:
>>
>> On 14 August 2014 18:12, Kurt Zeilenga <kurt.zeilenga at isode.com> 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='juliet at im.example.com'
>>>        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='juliet at im.example.com'
>>>        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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140814/e7af48f5/attachment.html>


More information about the Standards mailing list