Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Wed, Jan 4, 2012 at 2:26 PM, Matthew Miller
 wrote:
>
> On Jan 4, 2012, at 07:25, Dave Cridland wrote:
>
>> On Wed Jan  4 14:22:30 2012, Kevin Smith wrote:
>>> I think it'd be good to pick something and use it consistently,
>>> whatever that thing is.
>>
>> I'd like to paint it green.
>>
>
> Only if you know the Mayor of Boston.

I suggest we settle on 'side by side', then, if that's what MAM does
and the Carbons author(one of) is happy with it.

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew Miller]

On Jan 4, 2012, at 07:25, Dave Cridland wrote:

> On Wed Jan  4 14:22:30 2012, Kevin Smith wrote:
>> I think it'd be good to pick something and use it consistently,
>> whatever that thing is.
> 
> I'd like to paint it green.
> 

Only if you know the Mayor of Boston.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Use of Message Forwarding in other XEPs

[Dave Cridland]

On Wed Jan  4 14:22:30 2012, Kevin Smith wrote:

I think it'd be good to pick something and use it consistently,
whatever that thing is.


I'd like to paint it green.

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Wed, Jan 4, 2012 at 2:20 PM, Matthew Miller
 wrote:
>
> On Jan 4, 2012, at 05:46, Kim Alvefur wrote:
>
>> On Wed, 2012-01-04 at 11:24 +, Kevin Smith wrote:
>>> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
 On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
> 
 Isn't the  providing no information at all, here? (Not that it
 ever was).

 Surely it's entirely and completely implied by the .
>>>
>>> Other than making it nice and easy for clients to deal with the
>>> forwarded message. It's true we could put the children of 
>>> directly into every parent protocol that uses it (currently only two
>>> or three, I realise), but it's nice to be able to reuse the 'oh, it's
>>> a forward' parsing/serialising/whatever.
>>
>> I think that either what Kev said or this:
>>
>> 
>> 
>> 
>>  
>> 
>> 
>>
>> makes most sense.  (MattJs 137bis draft does this.)  With the later, you
>> can have some separation of metadata and content.
>>
>> But more importantly, I think that consistency among forwards-using XEPs
>> would be nice.
>
>
> I think this is a much better use than nesting  within whatever 
> sub-protocol there is.  At that point, I'd rather just have carbons element 
> contain the  directly and leave out the now-pointless
>
> However, I don't see a problem with the way it is now, if we're willing to 
> look at the other stuff in a forward as "context about the forward".  But I'm 
> willing to change the carbons elements to be outside the  if that's 
> the consensus.

I think it'd be good to pick something and use it consistently,
whatever that thing is.

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew Miller]

On Jan 4, 2012, at 05:46, Kim Alvefur wrote:

> On Wed, 2012-01-04 at 11:24 +, Kevin Smith wrote:
>> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
>>> On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
 
>>> Isn't the  providing no information at all, here? (Not that it
>>> ever was).
>>> 
>>> Surely it's entirely and completely implied by the .
>> 
>> Other than making it nice and easy for clients to deal with the
>> forwarded message. It's true we could put the children of 
>> directly into every parent protocol that uses it (currently only two
>> or three, I realise), but it's nice to be able to reuse the 'oh, it's
>> a forward' parsing/serialising/whatever.
> 
> I think that either what Kev said or this:
> 
> 
> 
> 
>  
> 
> 
> 
> makes most sense.  (MattJs 137bis draft does this.)  With the later, you
> can have some separation of metadata and content.
> 
> But more importantly, I think that consistency among forwards-using XEPs
> would be nice.


I think this is a much better use than nesting  within whatever 
sub-protocol there is.  At that point, I'd rather just have carbons element 
contain the  directly and leave out the now-pointless

However, I don't see a problem with the way it is now, if we're willing to look 
at the other stuff in a forward as "context about the forward".  But I'm 
willing to change the carbons elements to be outside the  if that's 
the consensus.


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Use of Message Forwarding in other XEPs

[Kim Alvefur]

On Wed, 2012-01-04 at 11:24 +, Kevin Smith wrote:
> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
> > On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
> >> 
> > Isn't the  providing no information at all, here? (Not that it
> > ever was).
> >
> > Surely it's entirely and completely implied by the .
> 
> Other than making it nice and easy for clients to deal with the
> forwarded message. It's true we could put the children of 
> directly into every parent protocol that uses it (currently only two
> or three, I realise), but it's nice to be able to reuse the 'oh, it's
> a forward' parsing/serialising/whatever.

I think that either what Kev said or this:


 
 
  
 


makes most sense.  (MattJs 137bis draft does this.)  With the later, you
can have some separation of metadata and content.

But more importantly, I think that consistency among forwards-using XEPs
would be nice.
-- 
Kim Alvefur 

Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Wed, Jan 4, 2012 at 11:51 AM, Dave Cridland  wrote:
> On Wed Jan  4 11:24:50 2012, Kevin Smith wrote:
>>
>> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
>> > On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
>> >> 
>> > Isn't the  providing no information at all, here? (Not that it
>> > ever was).
>> >
>> > Surely it's entirely and completely implied by the .
>>
>> Other than making it nice and easy for clients to deal with the
>> forwarded message. It's true we could put the children of 
>> directly into every parent protocol that uses it (currently only two
>> or three, I realise), but it's nice to be able to reuse the 'oh, it's
>> a forward' parsing/serialising/whatever.
>
>
> Rather than "Oh, it's a message"?
>
> Just seems tautological.

Although messages aren't the only possible children of .

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Dave Cridland]

On Wed Jan  4 11:24:50 2012, Kevin Smith wrote:
On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland   
wrote:

> On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
>> 
> Isn't the  providing no information at all, here? (Not  
that it

> ever was).
>
> Surely it's entirely and completely implied by the .

Other than making it nice and easy for clients to deal with the
forwarded message. It's true we could put the children of 
directly into every parent protocol that uses it (currently only two
or three, I realise), but it's nice to be able to reuse the 'oh,  
it's

a forward' parsing/serialising/whatever.


Rather than "Oh, it's a message"?

Just seems tautological.

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland  wrote:
> On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:
>> 
> Isn't the  providing no information at all, here? (Not that it
> ever was).
>
> Surely it's entirely and completely implied by the .

Other than making it nice and easy for clients to deal with the
forwarded message. It's true we could put the children of 
directly into every parent protocol that uses it (currently only two
or three, I realise), but it's nice to be able to reuse the 'oh, it's
a forward' parsing/serialising/whatever.

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Dave Cridland]

On Wed Jan  4 11:12:56 2012, Kevin Smith wrote:




Isn't the  providing no information at all, here? (Not that  
it ever was).


Surely it's entirely and completely implied by the .

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Fri, Dec 16, 2011 at 12:22 PM, Kevin Smith  wrote:
> On Thu, Dec 15, 2011 at 5:22 PM, Matthew Wild  wrote:
>> On 15 December 2011 15:27, Matthew A. Miller  
>> wrote:
>>> On Nov 1, 2011, at 15:36, Kim Alvefur wrote:
>>>
 Hi!

 I've noted that Message Forwarding [XEP-0297] doesn't give any
 recommendations for how (or if) you should indicate to which extension
 it belongs.  Is this something that would be desirable?

 Currently Message Carbons [XEP-0297] has what can be seen as an
 indicator inside the  element[1].  Would it be better or
 worse to, let's say, have this as a child of the parent ?

 1: http://xmpp.org/extensions/xep-0280.html#example-13
>>>
>>> To be honest, I don't remember why I chose to put the indicators as 
>>> children of the  instead of as siblings.  I can see either 
>>> pattern making sense, and am happy to change XEP-0280 if the current 
>>> pattern is too strange.
>>>
>>> Maybe one of XEP-0297's authors can comment on this?
>>>
>>
>> I'm inclined to say it should be a sibling. When you consider how an
>> application is going to sensibly handle this, it's going to first want
>> to categorize it as a carbons message before extracting the message
>> contents from . Partly the principle is that you can judge
>> a message type by the namespaces of its immediate children.
>
> I agree.

I have changed my mind, as indicated in the other thread. I think the
use of a forward should be a child of the using protocol. So for
carbons, you'd have:



The forward is a property of the carbon, not a property of the message
(Using the 'can use direct children to determine type of parent' idea
- Message "is a" Carbon, Carbon "is a" forward)

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Kevin Smith]

On Thu, Dec 15, 2011 at 5:22 PM, Matthew Wild  wrote:
> On 15 December 2011 15:27, Matthew A. Miller  
> wrote:
>> On Nov 1, 2011, at 15:36, Kim Alvefur wrote:
>>
>>> Hi!
>>>
>>> I've noted that Message Forwarding [XEP-0297] doesn't give any
>>> recommendations for how (or if) you should indicate to which extension
>>> it belongs.  Is this something that would be desirable?
>>>
>>> Currently Message Carbons [XEP-0297] has what can be seen as an
>>> indicator inside the  element[1].  Would it be better or
>>> worse to, let's say, have this as a child of the parent ?
>>>
>>> 1: http://xmpp.org/extensions/xep-0280.html#example-13
>>
>> To be honest, I don't remember why I chose to put the indicators as children 
>> of the  instead of as siblings.  I can see either pattern making 
>> sense, and am happy to change XEP-0280 if the current pattern is too strange.
>>
>> Maybe one of XEP-0297's authors can comment on this?
>>
>
> I'm inclined to say it should be a sibling. When you consider how an
> application is going to sensibly handle this, it's going to first want
> to categorize it as a carbons message before extracting the message
> contents from . Partly the principle is that you can judge
> a message type by the namespaces of its immediate children.

I agree.

/K

Re: [Standards] Use of Message Forwarding in other XEPs

[Peter Saint-Andre]

On 12/15/11 10:22 AM, Matthew Wild wrote:
> On 15 December 2011 15:27, Matthew A. Miller  
> wrote:
>> On Nov 1, 2011, at 15:36, Kim Alvefur wrote:
>>
>>> Hi!
>>>
>>> I've noted that Message Forwarding [XEP-0297] doesn't give any
>>> recommendations for how (or if) you should indicate to which extension
>>> it belongs.  Is this something that would be desirable?
>>>
>>> Currently Message Carbons [XEP-0297] has what can be seen as an
>>> indicator inside the  element[1].  Would it be better or
>>> worse to, let's say, have this as a child of the parent ?
>>>
>>> 1: http://xmpp.org/extensions/xep-0280.html#example-13
>>
>> To be honest, I don't remember why I chose to put the indicators as children 
>> of the  instead of as siblings.  I can see either pattern making 
>> sense, and am happy to change XEP-0280 if the current pattern is too strange.
>>
>> Maybe one of XEP-0297's authors can comment on this?
>>
> 
> I'm inclined to say it should be a sibling. When you consider how an
> application is going to sensibly handle this, it's going to first want
> to categorize it as a carbons message before extracting the message
> contents from . Partly the principle is that you can judge
> a message type by the namespaces of its immediate children.

Shades of XEP-0226, eh?

http://xmpp.org/extensions/xep-0226.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew Wild]

On 15 December 2011 15:27, Matthew A. Miller  wrote:
> On Nov 1, 2011, at 15:36, Kim Alvefur wrote:
>
>> Hi!
>>
>> I've noted that Message Forwarding [XEP-0297] doesn't give any
>> recommendations for how (or if) you should indicate to which extension
>> it belongs.  Is this something that would be desirable?
>>
>> Currently Message Carbons [XEP-0297] has what can be seen as an
>> indicator inside the  element[1].  Would it be better or
>> worse to, let's say, have this as a child of the parent ?
>>
>> 1: http://xmpp.org/extensions/xep-0280.html#example-13
>
> To be honest, I don't remember why I chose to put the indicators as children 
> of the  instead of as siblings.  I can see either pattern making 
> sense, and am happy to change XEP-0280 if the current pattern is too strange.
>
> Maybe one of XEP-0297's authors can comment on this?
>

I'm inclined to say it should be a sibling. When you consider how an
application is going to sensibly handle this, it's going to first want
to categorize it as a carbons message before extracting the message
contents from . Partly the principle is that you can judge
a message type by the namespaces of its immediate children.

Regards,
Matthew

Re: [Standards] Use of Message Forwarding in other XEPs

[Matthew A. Miller]

On Nov 1, 2011, at 15:36, Kim Alvefur wrote:

> Hi!
> 
> I've noted that Message Forwarding [XEP-0297] doesn't give any
> recommendations for how (or if) you should indicate to which extension
> it belongs.  Is this something that would be desirable?
> 
> Currently Message Carbons [XEP-0297] has what can be seen as an
> indicator inside the  element[1].  Would it be better or
> worse to, let's say, have this as a child of the parent ?
> 
> 1: http://xmpp.org/extensions/xep-0280.html#example-13

To be honest, I don't remember why I chose to put the indicators as children of 
the  instead of as siblings.  I can see either pattern making 
sense, and am happy to change XEP-0280 if the current pattern is too strange.

Maybe one of XEP-0297's authors can comment on this?


- m&m




smime.p7s
Description: S/MIME cryptographic signature

[Standards] Use of Message Forwarding in other XEPs

[Kim Alvefur]

Hi!

I've noted that Message Forwarding [XEP-0297] doesn't give any
recommendations for how (or if) you should indicate to which extension
it belongs.  Is this something that would be desirable?

Currently Message Carbons [XEP-0297] has what can be seen as an
indicator inside the  element[1].  Would it be better or
worse to, let's say, have this as a child of the parent ?

1: http://xmpp.org/extensions/xep-0280.html#example-13
-- 
Kim Alvefur 


signature.asc
Description: This is a digitally signed message part