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. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
