Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

[Thijs Alkemade]

> On 20 jan. 2016, at 19:16, Daniel Gultsch  wrote:
> 
> Hi,
> 
> while I see the general need for the added x Element in forwarded muc 
> messages. (I think i brought this up myself once in an earlier thread.) This 
> is missing a 'Security Consideration' that servers must remove the x element 
> if a users sends it. (In case the server is storing the entire stanza and not 
> just the Content of the body element.) Otherwise users can very easily spoof 
> messages as being from a different sender.
> 
> However the main problem is that even if the server removes those elements as 
> a client I still can't trust them because I don't know whether the server has 
> added the element or a malicious user.
> 
> I was always meaning to spark a conversation about server injecting elements 
> into stanzas that don't originate from them. (ejabberd for example is already 
> injecting the stanza-id (which don't get me wrong is a good thing in theory.) 
> The problem is not to sanitize those stanzas on the server side the problem 
> is that i don't know as a client.
> 
> I don't have a good solution to this yet and this should definitely go into a 
> different thread by maybe something about a special attribute for example 
> 'by' that indicates who injected that tag and a general rule to remove all 
> elements that have the attribute by with my entity - or something.
> 
> cheers
> Daniel

Hi Daniel,

I sent a proposal for that back in June [1], but that didn't receive a lot of
responses, just Kev noting that namespaced attributes aren't very common in
XMPP [2].

There are alternatives to using a namespaced attribute, but I fear those won't
be backwards compatible. Unless there are implementations out there that have
major problems working with namespaced attributes, I don't think we should
avoid them just for being rare.

Regards,
Thijs


[1] = http://mail.jabber.org/pipermail/standards/2015-June/029847.html
[2] = http://mail.jabber.org/pipermail/standards/2015-October/030514.html



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Dave Cridland]

On 20 January 2016 at 16:09, Peter Saint-Andre  wrote:

> On 1/19/16 9:49 AM, XMPP Extensions Editor wrote:
>
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Content Types in Messages
>>
>> Abstract: This specification describes a generic method whereby content
>> in messages can be tagged as having a specific Internet Content Type. It
>> also provides a method for sending the same content using different content
>> types, as a fall-back mechanism when communicating between clients having
>> different content type support.
>>
>> URL: http://xmpp.org/extensions/inbox/content-types.html
>>
>
> My opinion is that if we want to support text/markdown, let's write a spec
> for that.
>
> There is a large list of text media types here:
>
> http://www.iana.org/assignments/media-types/media-types.xhtml#text
>
> I don't think it's a great idea to support any arbitrary text format
> (sgml, troff, raptorfec, csv, etc.), in part because each one has different
> security implications.
>
>
I'd be happy to have a whitelist of media types we suggest.


> Peter
>
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Fwd: Council minutes 2016-01-20

[Sam Whited]

FYI


-- Forwarded message --
From: Sam Whited 
Date: Wed, Jan 20, 2016 at 10:14 AM
Subject: Council minutes 2016-01-20
To: coun...@xmpp.org


# 2016-01-20 Council Meeting

Logs: http://logs.xmpp.org/council/2016-01-20/#16:00:22

## Roll call

- Lance
- Dave
- Tobi
- MattJ
- psa

## JID Mention: Accept as Experimental?

http://xmpp.org/extensions/inbox/jid-mention.html

- MattJ on list
- Tobi on list

Dave notes that "it looks like half a solution"

- Dave on list
- psa on list
- Lance on list

## Content types: Accept as Experimental?

http://xmpp.org/extensions/inbox/content-types.html

- Dave +1
- Tobi on list

- psa notes that he's "not really sure if we want to be supporting text/sgml or
text/raptorfec or or text/troff or any arbitrary format"

- psa on list

- MattJ -1
- Lance on list

## Date of next

2016-02-03 1600 UTC

Dave notes that we could do a Council meeting at the Summit if enough people
are there.

## AOB

None

EOM


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: JID Mention

[Dave Cridland]

On 19 January 2016 at 16:48, XMPP Extensions Editor  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: JID Mention
>
> Abstract: This specification provides a way for an entity to mention a jid
>

No, it doesn't. It provides a way to notify an entity that its jid has been
mentioned.


>
> URL: http://xmpp.org/extensions/inbox/jid-mention.html
>
>
I don't know if you've considered this, but currently the "other end" of
the mention has no markup, and so would be performed by string matching
either in the client or the server. Both are frail, and subject to
mismatches (or typos causing no match at all).

I wonder if having a corresponding  in a message (or post) might
be the answer?

My gut feeling - which may well be wrong - is that the two halves
(mentioning and notifying about it) would be better placed in the same XEP.


> The XMPP Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

[Daniel Gultsch]

Hi,

while I see the general need for the added x Element in forwarded muc
messages. (I think i brought this up myself once in an earlier thread.)
This is missing a 'Security Consideration' that servers must remove the x
element if a users sends it. (In case the server is storing the entire
stanza and not just the Content of the body element.) Otherwise users can
very easily spoof messages as being from a different sender.

However the main problem is that even if the server removes those elements
as a client I still can't trust them because I don't know whether the
server has added the element or a malicious user.

I was always meaning to spark a conversation about server injecting
elements into stanzas that don't originate from them. (ejabberd for example
is already injecting the stanza-id (which don't get me wrong is a good
thing in theory.) The problem is not to sanitize those stanzas on the
server side the problem is that i don't know as a client.

I don't have a good solution to this yet and this should definitely go into
a different thread by maybe something about a special attribute for example
'by' that indicates who injected that tag and a general rule to remove all
elements that have the attribute by with my entity - or something.

cheers
Daniel

2016-01-20 18:27 GMT+01:00 XMPP Extensions Editor :

> Version 0.5 of XEP-0313 (Message Archive Management) has been released.
>
> Abstract: This document defines a protocol to query and control an archive
> of messages stored on a server.
>
> Changelog: [See revision history] (XEP Editor (mam))
>
> Diff: http://xmpp.org/extensions/diff/api/xep/0313/diff/0.4.1/vs/0.5
>
> URL: http://xmpp.org/extensions/xep-0313.html
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Peter Saint-Andre]

On 1/19/16 9:49 AM, XMPP Extensions Editor wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Content Types in Messages

Abstract: This specification describes a generic method whereby content in 
messages can be tagged as having a specific Internet Content Type. It also 
provides a method for sending the same content using different content types, 
as a fall-back mechanism when communicating between clients having different 
content type support.

URL: http://xmpp.org/extensions/inbox/content-types.html


My opinion is that if we want to support text/markdown, let's write a 
spec for that.


There is a large list of text media types here:

http://www.iana.org/assignments/media-types/media-types.xhtml#text

I don't think it's a great idea to support any arbitrary text format 
(sgml, troff, raptorfec, csv, etc.), in part because each one has 
different security implications.


Peter

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Matthew Wild]

On 19 January 2016 at 16:49, XMPP Extensions Editor  wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Content Types in Messages
>
> Abstract: This specification describes a generic method whereby content in 
> messages can be tagged as having a specific Internet Content Type. It also 
> provides a method for sending the same content using different content types, 
> as a fall-back mechanism when communicating between clients having different 
> content type support.
>
> URL: http://xmpp.org/extensions/inbox/content-types.html
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.

I just voted against this proposal today, for the following reasons:

 - I'm not seeing any consensus in favour of this approach on the
list. Mostly only concerns.

 - I don't believe the problem the specification was written to solve
(including markdown *and* "plaintext" in a single message) is a
problem that needs solving. We already have a standard for
communicating plaintext content () and a standard for
communicating formatted content (XHTML-IM). I don't think we need any
more.

 - Adding more (optionally rendered) representations of the content
into a single message increases bandwidth. There is no mechanism to
discover what content types the recipient will understand. Such a
discovery mechanism, if added, would also be complicated (e.g. the
recipient may not be online).

 - Adding more (optionally rendered) representations of the content of
a message introduces further complication into knowing which version
of the content any particular client will display, potentially leading
to security concerns.

 - Unclear interaction with XEPs that encrypt the plaintext content in
a message.

 - Unclear interaction with archiving (e.g. which version(s) of the
content should be archived?)

 - Unclear interaction with xml:lang

 - Not interoperable with existing clients (some of which already
support markdown, and *are* interoperable with other existing clients,
thanks to  and XHTML-IM), it is just causing fragmentation and
yet another markup format for clients to implement if they want to
render formatted messages.

 - Finally, regarding Markdown specifically, many noted there is no
commonly-accepted standard, so a simple mimetype would not be enough
to unambiguously describe the format of the content in this case
anyway.

Regards,
Matthew
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: JID Mention

[Goffi]

Hi Dave,

Le mercredi 20 janvier 2016, 16:19:52 Dave Cridland a écrit :
> > URL: http://xmpp.org/extensions/inbox/jid-mention.html
> 
> I don't know if you've considered this, but currently the "other end" of
> the mention has no markup, and so would be performed by string matching
> either in the client or the server. Both are frail, and subject to
> mismatches (or typos causing no match at all).

I'm not sure to understand, the "matching syntax" is let to the client 
implementation on purpose (see section 4.1), as I don't want to enforce 
"@nick" syntax because it's the fashion today (but clients can use it if they 
want to).

as I imagine it, if a user wants to mention an other user in a blog or a 
conversation, it can press @ (or use a menu, or anything), then the client 
show a list of potential contacts, then the message is sent with the  
element. The mentioned entity receive the message and check the from attribute 
(or the  element). I don't see where string matching is needed.

But maybe I misunderstood your point. By "other end" are talking about the 
mentioned entity or the mentioning entity?

++
Goffi
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: JID Mention

[Dave Cridland]

On 20 January 2016 at 16:43, Goffi  wrote:

> Hi Dave,
>
> Le mercredi 20 janvier 2016, 16:19:52 Dave Cridland a écrit :
> > > URL: http://xmpp.org/extensions/inbox/jid-mention.html
> >
> > I don't know if you've considered this, but currently the "other end" of
> > the mention has no markup, and so would be performed by string matching
> > either in the client or the server. Both are frail, and subject to
> > mismatches (or typos causing no match at all).
>
> I'm not sure to understand, the "matching syntax" is let to the client
> implementation on purpose (see section 4.1), as I don't want to enforce
> "@nick" syntax because it's the fashion today (but clients can use it if
> they
> want to).
>
> as I imagine it, if a user wants to mention an other user in a blog or a
> conversation, it can press @ (or use a menu, or anything), then the client
> show a list of potential contacts, then the message is sent with the
> 
> element. The mentioned entity receive the message and check the from
> attribute
> (or the  element). I don't see where string matching is needed.
>
> But maybe I misunderstood your point. By "other end" are talking about the
> mentioned entity or the mentioning entity?
>
>
The mentioning entity. But really, I'd like to have chatrooms send these
out rather than the mentioning client, and the mention have some markup
injected by the client so we're not string matching *there* - I agree the
client doesn't need to.

So:

1) I mention you in a chatroom:


  SamWhited, Hey, Goffi's working on something clever.
  go...@example.comsamwhi...@example.net



2) The chatroom (MIX/MUC) can see SamWhited's presence in the room, so
knows he'll see that anyway. But maybe you're offline - so it sends you the
notification so you know to catch up, using the protocol you're proposing.

3) When you're back online, the chatroom might even send the notification
*then*, rather like a lot of bots do now.

Still, all this thinking obviously means I think we should formalize
"mentions" into protocol, so +1 to this spec, even if I think we need to
add in the formalized mention as well as the notification.

++
> Goffi
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] UPDATED: XEP-0313 (Message Archive Management)

[Daniel Gultsch]

Hi Thijs,

2016-01-20 19:36 GMT+01:00 Thijs Alkemade :

> I sent a proposal for that back in June [1], but that didn't receive a lot
> of
> responses, just Kev noting that namespaced attributes aren't very common in
> XMPP [2].
>
> There are alternatives to using a namespaced attribute, but I fear those
> won't
> be backwards compatible. Unless there are implementations out there that
> have
> major problems working with namespaced attributes, I don't think we should
> avoid them just for being rare.
>
> Regards,
> Thijs
>
>
> [1] = http://mail.jabber.org/pipermail/standards/2015-June/029847.html
> [2] = http://mail.jabber.org/pipermail/standards/2015-October/030514.html
>

yeah too bad that this didn't get any attention. I kinda missed that
myself. That's probably not an easy topic to grasp if you never thought
about it before.
Never the less this problem needs a solution and I actually belief it's
careless to just update XEPs like this.

I had a quick off-list discussion about this and for most scenarios  might
have individual solutions available. In this MAM case this could have been
solved by a namespace bump and the requirement for servers to sanitize
those elements.

In case of a server injecting stanza-ids it could probably be solved by
having the server announce the stanza-id namespace in its disco and thus
indicating that it is sanitizing all stanza-ids.

Like you mentioned using an un-namespaced from or by attribute can lead to
some weird consequences.

What ever we agree on we should come up with a solution rather sooner than
later. Because having the server inject information like the original
sender in this case or stanza-ids in another is certainly something
desirable. But without the added security practically worthless.

cheers
Daniel
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: JID Mention

[Goffi]

Le mercredi 20 janvier 2016, 19:43:30 Dave Cridland a écrit :
> On 20 January 2016 at 16:43, Goffi  wrote:
> [...]
> 
> 3) When you're back online, the chatroom might even send the notification
> *then*, rather like a lot of bots do now.
> 
> Still, all this thinking obviously means I think we should formalize
> "mentions" into protocol, so +1 to this spec, even if I think we need to
> add in the formalized mention as well as the notification.


There is a point I haven't said so far, it is that I plan to propose (probably 
after Fosdem) an other protoXEP to indicate to server how to handle offline 
notifications.

Right now if I have a mention and I'm online, it's alright I can display it to 
the user. If I'm offline, only the server know that I have a notification.
So I want to be able to tell to the server « when I'm offline and I have this 
kind of notification, send me an email [or something else], when I'm online, 
I'll handle it myself thanks »

The reason I want to make a generic option server side, is that I want to 
handle PubSub notifications in addition to mentions: e.g. I want to be able to 
say to my server « I want an email when somebody reply to a comment and I'm 
not online, but I don't want notification if somebody mention me ». Also the 
server can know user email address thanks to vcard. So it make more sense for 
me to handle offline notification on the server rather than on components.

++
Goffi
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0313 (Message Archive Management)

[XMPP Extensions Editor]

Version 0.5 of XEP-0313 (Message Archive Management) has been released.

Abstract: This document defines a protocol to query and control an archive of 
messages stored on a server.

Changelog: [See revision history] (XEP Editor (mam))

Diff: http://xmpp.org/extensions/diff/api/xep/0313/diff/0.4.1/vs/0.5

URL: http://xmpp.org/extensions/xep-0313.html

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: JID Mention

[Sam Whited]

On Wed, Jan 20, 2016 at 1:43 PM, Dave Cridland  wrote:
> 2) The chatroom (MIX/MUC) can see SamWhited's presence in the room, so knows
> he'll see that anyway. But maybe you're offline - so it sends you the
> notification so you know to catch up, using the protocol you're proposing.

I think it's broken, that appears to have mentioned me over some
archaic mail protocol instead of in my XMPP client ☺

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Ashley Ward]

> On 19 Jan 2016, at 19:41, Matthieu Rakotojaona 
>  wrote:
> 
> It looks like this XEP hands messages that have a single 
> element, but the RFC says you can have multiple elements, each with
> its own xml:lang. Is it expected that this works only with single
>  elements ?
> 
> Side question: are there uses of multiple  elements with
> different xml:lang ?

Very good point. If there are multiple  elements in different languages 
then they should be in the same format, so I assume the type hint should apply 
to all of them. Maybe update the EXP to clarify?

—
Ash

smime.p7s
Description: S/MIME cryptographic signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Goffi]

Le mercredi 20 janvier 2016, 09:33:46 Goffi a écrit :
> Le mardi 19 janvier 2016, 16:49:22 XMPP Extensions Editor a écrit :
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> > 
> > Title: Content Types in Messages
> > 
> > Abstract: This specification describes a generic method whereby content in
> > messages can be tagged as having a specific Internet Content Type. It also
> > provides a method for sending the same content using different content
> > types, as a fall-back mechanism when communicating between clients having
> > different content type support.
> > 
> > URL: http://xmpp.org/extensions/inbox/content-types.html
> 
> Hello,
> 
> I still think this XEP is a false good idea, as I said in last week
> discussion. Here are the main reasons:
> 
>   - there are already a couple of projects using markdown through the
> standardized XHTML-IM. With this XEP, we'll have some markdown in a
>  element, some converted in XHTML-IM, which one should I use?
> 
>   - mardown is not a standard, and the only tentative to standardize it
> (CommonMark) is not popular for the moment (not even sure of its status at
> all)
> 
>   - even if a standard was there, there are and will probably always be
> different flavours. In other terms, every client will tend to have slightly
> different rendering, in the opposition of what XMPP currently offers or try
> to offers (same thing on each screen in the same order).
> 
>   - beside markdown, other syntaxes will be used, each client having its
> favorite one. This will bring more fragmentation
> 
>   - today we have 2 types contents: plain text and rich (XHTML-IM). I 
> don't
> see any reason to add on extra one, or at least a syntax which translate
> trivially to XHTML is not a good reason to add a new content for me.
> 
>   - XHTML/XHTML-IM being XML, so using the same kind of parser that what 
> is
> already used for XMPP, it seems the natural option for rich content. If the
> goal of all this is to edit markdown, we do convert XHTML => markdown, and
> it's working reasonably well, specially for the limited set of elements that
> we have in XHTML-IM
> 
>   - I would rather see markdown put as text content (without hint or
> anything), than having extra elements with any possible syntax.
> 
> 
> In addition I wonder what is the point of this? For instant messaging, it's
> not common to edit text, or with last message correction (and client can
> keep the last message original syntax in cache trivially). Why not doing
> the conversion markdown => XHTML-IM client side before sending the message?
> 
> For blogging, it's more natural to use XHTML, and anyway this XEP doesn't
> cover the case (blogging use PubSub, not messages).
> 
> 
> Regards
> Goffi


just thinking about an other issue: current encryption method (OTR and soon to 
be released OMEMO) encrypt only the  element - which is in my opinion a 
bad practice, but this is an other topic -, so addind a  element 
will make it appears in clear.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Content Types in Messages

[Goffi]

Le mardi 19 janvier 2016, 16:49:22 XMPP Extensions Editor a écrit :
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Content Types in Messages
> 
> Abstract: This specification describes a generic method whereby content in
> messages can be tagged as having a specific Internet Content Type. It also
> provides a method for sending the same content using different content
> types, as a fall-back mechanism when communicating between clients having
> different content type support.
> 
> URL: http://xmpp.org/extensions/inbox/content-types.html

Hello,

I still think this XEP is a false good idea, as I said in last week 
discussion. Here are the main reasons:

- there are already a couple of projects using markdown through the 
standardized XHTML-IM. With this XEP, we'll have some markdown in a  
element, some converted in XHTML-IM, which one should I use?

- mardown is not a standard, and the only tentative to standardize it 
(CommonMark) is not popular for the moment (not even sure of its status at 
all)

- even if a standard was there, there are and will probably always be 
different flavours. In other terms, every client will tend to have slightly 
different rendering, in the opposition of what XMPP currently offers or try to 
offers (same thing on each screen in the same order).

- beside markdown, other syntaxes will be used, each client having its 
favorite one. This will bring more fragmentation

- today we have 2 types contents: plain text and rich (XHTML-IM). I 
don't 
see any reason to add on extra one, or at least a syntax which translate 
trivially to XHTML is not a good reason to add a new content for me.

- XHTML/XHTML-IM being XML, so using the same kind of parser that what 
is 
already used for XMPP, it seems the natural option for rich content. If the 
goal of all this is to edit markdown, we do convert XHTML => markdown, and 
it's working reasonably well, specially for the limited set of elements that 
we have in XHTML-IM

- I would rather see markdown put as text content (without hint or 
anything), than having extra elements with any possible syntax.


In addition I wonder what is the point of this? For instant messaging, it's 
not common to edit text, or with last message correction (and client can keep 
the last message original syntax in cache trivially). Why not doing the 
conversion markdown => XHTML-IM client side before sending the message?

For blogging, it's more natural to use XHTML, and anyway this XEP doesn't 
cover the case (blogging use PubSub, not messages).


Regards
Goffi
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___