On Wed, Jan 4, 2012 at 2:20 PM, Matthew Miller <[email protected]> wrote: > > On Jan 4, 2012, at 05:46, Kim Alvefur wrote: > >> On Wed, 2012-01-04 at 11:24 +0000, Kevin Smith wrote: >>> On Wed, Jan 4, 2012 at 11:18 AM, Dave Cridland <[email protected]> wrote: >>>> On Wed Jan 4 11:12:56 2012, Kevin Smith wrote: >>>>> <message><carbon><forward><message/></forward></carbon></message> >>>> Isn't the <forward/> providing no information at all, here? (Not that it >>>> ever was). >>>> >>>> Surely it's entirely and completely implied by the <carbon/>. >>> >>> Other than making it nice and easy for clients to deal with the >>> forwarded message. It's true we could put the children of <forward> >>> 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: >> >> <message> >> <which-protocol/> >> <forward> >> <something/> >> </forward> >> </message> >> >> 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 <forward/> within whatever > sub-protocol there is. At that point, I'd rather just have carbons element > contain the <message/> 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 <forward/> if that's > the consensus.
I think it'd be good to pick something and use it consistently, whatever that thing is. /K
