On 05/30/2008 1:45 PM, Robert McQueen wrote: > Peter Saint-Andre wrote: >> On 05/29/2008 1:38 PM, Robert McQueen wrote: >>> Peter Saint-Andre wrote: >>> I think I'm in favour of this, given the two XEPs seem to be copies of >>> each other. We could just have one RTP/AVP description XEP, with a media >>> type field. >> Yes I looked into that a while back. For instance we might have this: > > ... > >> So while I think that including the media type as attributes of the >> <content/> element is helpful in some instances, it doesn't give you >> everything you need in order to determine whether you want to accept the >> negotiation or whatever. > > Aiee! This seems like crazy over-generalisation to me. Every different > content description markup will have its own way of describing what it > wants to do (if necessary), especially when we do stuff like re-using > existing namespaces like file transfer. > > Why would you you want to say in two places you're doing audio, or say > in one place you're doing audio, and somewhere else say you're doing it > over RTP? Not to mention it would invoke yet another registry of > namespaces/values/attributes we have to take care of.
Yeah ignore that ramble I sent. > I was thinking of a direct analogy to the media field saying "audio" or > "video" in your m-line in SDP. So like: > > <jingle> > <content name="asdf"> > <description xmlns="...rtp" media="audio"> > <payload-type> > <payload-type> > </description> > <transport/> > </content> > </jingle> > > Then we'd just define some features to explain what media you supported, > like: > > urn:...:jingle-rtp#media-audio > urn:...:jingle-rtp#media-video Works for me. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
