Robert McQueen
07-22-2008, 01:10 AM
Most of this is pretty minor...
XEP-0166 Section 5/Table 2:
• In content-add and content-replace, what does it mean to "ignore"
actions received from the other party? Drop on the floor, return an
error, ack but do nothing? Certainly if each content is uniquely
identified by (creator, name), there's no problem with two adds taking
place simultaneously, or other stuff like transport-info or
content-modify on other contents, etc.
• content-modify can probably be sent in reply to an unacceptable
content-modify, you just have to not reply twice, or something... :D
• The documented handling of two crossing over "content-replace" actions
is broken - both ends can't just ignore it. I suggest the initiator-wins
tiebreak, so when the initiator gets a content-replace for a content he
was trying to replace, he responds with an error saying he was already
doing it, and the responder discards his proposed replacement if he gets
one from the initiator, and ignores the error.
• use of the wording "content type" in section 5 is misleading, each
content-* action is just for one content in the session (ie, you can
have >1 instance of a type in a session)
Other XEP-0166 stuff:
• 6.4 - removing streams when the session is pending is OK
• 7.2 - emphasise that the name is unique for the creator
• 7.3 - is <condition> really necessary, and can't the reason-specific
fields (eg <sid>) be a child of that reason?
• condition list in schema is incomplete
XEP-0167
• 9.2 - stun checks should be marked as === out of XMPP
• get rid of profile! example 9.4 seems pretty half-baked, if you want
to add security to the RTP session, add an element which can be included
under the RTP <description> with the security information *or* as some
<transport> which adds it, but it should be signalled one way or the other.
• not sure I need to be acknowledged as well as an being listed as an
author? :D
XEP-0176
• 5.1 - stun checks should be marked with === too?
• examples have profile= in <content>
• 5.7 - replace doesn't have <description> is, but the reply does. maybe
"transport-replace" is less scary?
XEP-0181
• why does this exist? it's less interoperable than proper RFC 4733
events, and has all sorts of timing ambiguity - signalling path
differing from streaming path, so you push buttons, keep talking, then
the other end gets your DTMF XML 2 seconds later, and plays over your
speech... I don't really understand why we don't just say "use telephone
events" in the RTP XEP.
XEP-0234
• 2 - show non-XMPP content as ===?
• example 1 - do we need another level of <offer> below <description>?
the action should imply it correctly.
• 3.1 I really don't like the implication that >1 content of the same
type is for the purpose of transport fallbacks, it seems at odds with
multi-content calls. duplication of file description seems bad too.
• example 11 - content remove shouldn't have all the stuff in it
• example 23 - surely this can be ~empty too?
• example 27 - describes the wrong file offer...?
XEP-0166 Section 5/Table 2:
• In content-add and content-replace, what does it mean to "ignore"
actions received from the other party? Drop on the floor, return an
error, ack but do nothing? Certainly if each content is uniquely
identified by (creator, name), there's no problem with two adds taking
place simultaneously, or other stuff like transport-info or
content-modify on other contents, etc.
• content-modify can probably be sent in reply to an unacceptable
content-modify, you just have to not reply twice, or something... :D
• The documented handling of two crossing over "content-replace" actions
is broken - both ends can't just ignore it. I suggest the initiator-wins
tiebreak, so when the initiator gets a content-replace for a content he
was trying to replace, he responds with an error saying he was already
doing it, and the responder discards his proposed replacement if he gets
one from the initiator, and ignores the error.
• use of the wording "content type" in section 5 is misleading, each
content-* action is just for one content in the session (ie, you can
have >1 instance of a type in a session)
Other XEP-0166 stuff:
• 6.4 - removing streams when the session is pending is OK
• 7.2 - emphasise that the name is unique for the creator
• 7.3 - is <condition> really necessary, and can't the reason-specific
fields (eg <sid>) be a child of that reason?
• condition list in schema is incomplete
XEP-0167
• 9.2 - stun checks should be marked as === out of XMPP
• get rid of profile! example 9.4 seems pretty half-baked, if you want
to add security to the RTP session, add an element which can be included
under the RTP <description> with the security information *or* as some
<transport> which adds it, but it should be signalled one way or the other.
• not sure I need to be acknowledged as well as an being listed as an
author? :D
XEP-0176
• 5.1 - stun checks should be marked with === too?
• examples have profile= in <content>
• 5.7 - replace doesn't have <description> is, but the reply does. maybe
"transport-replace" is less scary?
XEP-0181
• why does this exist? it's less interoperable than proper RFC 4733
events, and has all sorts of timing ambiguity - signalling path
differing from streaming path, so you push buttons, keep talking, then
the other end gets your DTMF XML 2 seconds later, and plays over your
speech... I don't really understand why we don't just say "use telephone
events" in the RTP XEP.
XEP-0234
• 2 - show non-XMPP content as ===?
• example 1 - do we need another level of <offer> below <description>?
the action should imply it correctly.
• 3.1 I really don't like the implication that >1 content of the same
type is for the purpose of transport fallbacks, it seems at odds with
multi-content calls. duplication of file description seems bad too.
• example 11 - content remove shouldn't have all the stuff in it
• example 23 - surely this can be ~empty too?
• example 27 - describes the wrong file offer...?