On 11 June 2018 at 09:47, Klaus Herberth wrote:
> Hi everyone,
>
> I plan to implement XEP-0308 Last Message Correction [1] and I'm asking
> myself how I should handle corrections of older messages. The XEP just
> says: "While it is possible to use this protocol to correct messages
> older than t
> I don't want to put words in anybody's mouth, but to me it looks like
> Kev said it would be better to bump this than to have a second
> specification, not that changing this spec needs a bump.
"That was my original expectation too, but Kev suggested the bump would be
preferable. [...to a secon
> This wouldn’t be an issue if clients use sufficiently unique IDs.
I'm not sure that magically fixes the issue.
New RMC clients can and should use unique IDs - and we can mandate that - but
the issue here is with older LMC non-RMC-aware clients.So, if those clients
expect LMC to only ever be ap
* Tedd Sterr [2018-06-11 18:31]:
> That was my original expectation too, but Kev suggested the bump would be
> preferable.
I don't want to put words in anybody's mouth, but to me it looks like
Kev said it would be better to bump this than to have a second
specification, not that changing this sp
On Montag, 11. Juni 2018 18:29:50 CEST Tedd Sterr wrote:
> Upon receiving an RMC message, an LMC client would check whether the ID
> matches its last message and see that it doesn't -- the first business rule
> suggests that means it is a correction to a message directed to another
> resource, and
> It sounded to me like this would be a new distinct namespace
> older-than-previous-message corrections, a namespace bump may be more
> contentious in a draft XEP.
That was my original expectation too, but Kev suggested the bump would be
preferable.
> As I see it, the *worst* thing that will
On 11 Jun 2018, at 15:20, Sam Whited wrote:
>
> On Mon, Jun 11, 2018, at 09:15, Kevin Smith wrote:
>> I’m not sure that’s necessary, given that the current protocol was
>> designed to allow exactly this.
>
> Was it? I was reading this whole conversation in the context of:
>
>> support for this
* Sam Whited [2018-06-11 16:20]:
> I'm also not sure that one would be necessary, if we can get away with
> no new protocol or namespaces I'd be very happy.
Which is exactly why I asked the (non-rhetorical, seriously intended)
question I asked further above in this thread, which nobody seems to
h
On Mon, Jun 11, 2018, at 09:15, Kevin Smith wrote:
> I’m not sure that’s necessary, given that the current protocol was
> designed to allow exactly this.
Was it? I was reading this whole conversation in the context of:
> support for this SHOULD NOT be assumed without further negotiation.
which
On 11 Jun 2018, at 15:11, Sam Whited wrote:
>
> On Mon, Jun 11, 2018, at 09:02, Tedd Sterr wrote:
>> As long as it doesn't confuse existing implementations, hopefully
>> nothing; but I suppose that's what the namespace bump is for.
>
> It sounded to me like this would be a new distinct namespac
On Mon, Jun 11, 2018, at 09:02, Tedd Sterr wrote:
> As long as it doesn't confuse existing implementations, hopefully
> nothing; but I suppose that's what the namespace bump is for.
It sounded to me like this would be a new distinct namespace
older-than-previous-message corrections, a namespace
> What is the worst thing that happens if we just change this Draft?
As long as it doesn't confuse existing implementations, hopefully nothing; but
I suppose that's what the namespace bump is for.
___
Standards mailing list
Info: https://mail.jabber.o
> Is that essentially https://xmpp.org/extensions/inbox/message-retraction.html
> ?
The intent is roughly the same, though this looks to be aimed more at use in
MUC, and has additional complexities as a result.
I think considering deletion as a correction makes some sense, though I can see
h
* Tedd Sterr [2018-06-11 15:53]:
> > I think an ns bump in 308 is better than a duplicate spec, really (unless
> > there’s something I’m missing).
>
> I'm not strongly for a new spec.
What is the worst thing that happens if we just change this Draft?
Georg
signature.asc
Description: PGP sig
> I think an ns bump in 308 is better than a duplicate spec, really (unless
> there’s something I’m missing).
I'm not strongly for a new spec., though I thought it might be more appropriate
in this case given the aversion to changing Drafts and that it's already well
implemented; also avoiding
On 11 Jun 2018, at 13:52, Tedd Sterr wrote:
> and add deletion too (functionally, replacing the message with "This message
> was deleted.", but semantically different from literally replacing the
> message with that text.)
Is that essentially https://xmpp.org/extensions/inbox/message-retractio
On 11 Jun 2018, at 13:52, Tedd Sterr wrote:
>
> I have considered this issue previously and concluded that, while there
> appears to be no technical reason to disallow correcting older messages,
> (some) current implementations only support correction of the last message
> (in line with this l
On Mon, Jun 11, 2018, at 07:52, Tedd Sterr wrote:
> I think a fix would preferably have a new namespace, and so it's
> probably best to just create "(Recent) Message Correction" as a new XEP,
> even though it would be near identical to 0308. And I'd take the
> opportunity to tighten the business
I have considered this issue previously and concluded that, while there appears
to be no technical reason to disallow correcting older messages, (some) current
implementations only support correction of the last message (in line with this
limitation.)
Maybe Kev can shed some light on why this l
пн, 11 июн. 2018 г. в 14:21, Georg Lukas :
> The XEP requires the sending client to generate IDs:
>
> | Clients MUST send ids on messages if they allow the user to correct
> | messages.
>
> I wish it would require *unique* IDs, but that's what we've got, and a
> reasonable client will use unique ID
* Ненахов Андрей [2018-06-11 11:05]:
> The only technical reason for doing only last message correction is a
> possible absence of unique id in sent message.
The XEP requires the sending client to generate IDs:
| Clients MUST send ids on messages if they allow the user to correct
| messages.
I
> I really dislike that part of the XEP, because you can not rely on
> anything here. My client will allow modifying messages older than the
> last one (there is really no *technical* need for this restriction), and
> you can't prevent abuse of this feature anyway.
The only technical reason for do
* Klaus Herberth [2018-06-11 10:49]:
> The XEP just says: "While it is possible to use this protocol to
> correct messages older than the most recent received from a full JID,
> such use is out of scope for this document and support for this SHOULD
> NOT be assumed without further negotiation.",
23 matches
Mail list logo
