On Thu, May 30, 2013 at 8:22 PM, Christian Vogler <
christian.vog...@gallaudet.edu> wrote:
> 5. Is the specification accurate and clearly written?
>
> Yes. One of the best-written technical specs I have worked with.
>
Thanks for the compliment on XEP-0301
I couldn't have done it with all of you.
Dier Michal,
I'm interested in this activity in terms of machine-to-machine
communication/configuration over XMPP.
Regards,
Yusuke
(2013-05-30 16:04), Michal 'vorner' Vaner wrote:
Hello
I'm working with protocol called NetConf (RFC 6241) now. The protocol can be
used to configure devices r
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
> to clarify an existing protocol?
>
Yes. Real-time text has been a communication mode of choice for many deaf
and hard of hearing people, as well as people in the mainstream, and it has
been disconcerting to see it disap
1. Is this specification needed to fill gaps in the XMPP protocol stack or to
clarify an existing protocol?
Yes - Real-time text is important for some applications and required for
others (real time captioning). Regs are making it mandatory in some spheres.
And XMPP should be able to be use
On 5/30/13 1:04 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> I'm working with protocol called NetConf (RFC 6241) now. The protocol can be
> used to configure devices remotely over something more standardized than web
> interface or ssh & command line utilities (which is good for people but not
>
On Thu, May 30, 2013 at 7:10 PM, Justin Karneges wrote:
> Message Stanza Profiles (XEP-0226) may possibly be relevant to this
> discussion. It proposes that each message stanza should have a singular,
> deterministic purpose.
>
Possibly, though I think this is largely a case of annotation to inf
On 05/30/2013 10:58 AM, Dave Cridland wrote:
I was chatting with Matt earlier about this and related issues, and we
tossed around the idea of a processing hints marker, such that a sender
could indicate that there was no point archiving, or that carbons were
useless (because the message used OTR
I was chatting with Matt earlier about this and related issues, and we
tossed around the idea of a processing hints marker, such that a sender
could indicate that there was no point archiving, or that carbons were
useless (because the message used OTR, perhaps), or that the message was
actually use
On 28 May 2013 21:44, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Chat Markers
>
> Abstract: This specification describes a solution of marking the last
> received, read and acknowledged message in a chat.
>
> URL: http://xmpp.org/e
>
>
>
> Why? Both sender and receiving server can reuse XEP-0203.
>
When chatting in real time messages dont have the "archive's"
timestamp associated with them.
On Thu, May 30, 2013 at 12:06 PM, Philipp Hancke
wrote:
> Am 29.05.2013 10:40, schrieb Spencer MacDonald:
>
> IQ vs Message
>>
>> A
Am 29.05.2013 10:40, schrieb Spencer MacDonald:
IQ vs Message
A message based approaches was considered as both chat states and delivery
receipts use them, but it had the following disadvantages:
- You lose the ability for the server to insert timestamps.
Why? Both sender and receiving server
I don't think it needs to know about resources, because like you said
montague.lit
can forward it onto the interested parties.
For MUC the 'room' is in the chat marker so I don't think anything changes
for this.
Spencer
On Wed, May 29, 2013 at 8:00 AM, Lance Stout wrote:
>
> On May 28, 2013,
Hello
On Thu, May 30, 2013 at 09:43:43AM +0200, Steffen Larsen wrote:
> I am not into NetConf, but is it not RPC calls?
> If so, you can probably use XEP-009: http://xmpp.org/extensions/xep-0009.html
Part of NetConf is RPC, but from fast look at this XEP, it's different RPC (the
elements used ar
I need what chat markers provides (synchronised delivery and
read receipts across multiple resources) for a project I am currently
working on (hence me proposing it).
>From a previous thread there are already people implementing a custom
version of this in production apps.
Regards
Spencer
On T
Are there already projects considering to implement this?
Cheers,
Andreas
XMPP Extensions Editor:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Chat Markers
>
> Abstract: This specification describes a solution of marking the last
> received, read and acknowle
Hi Michal,
I am not into NetConf, but is it not RPC calls?
If so, you can probably use XEP-009: http://xmpp.org/extensions/xep-0009.html
-Cheers!
/Steffen
On May 30, 2013, at 9:04 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> I'm working with protocol called NetConf (RFC 6241) now. The protoc
Hello
I'm working with protocol called NetConf (RFC 6241) now. The protocol can be
used to configure devices remotely over something more standardized than web
interface or ssh & command line utilities (which is good for people but not for
automated scripts).
The protocol uses XML messages and de
17 matches
Mail list logo
