Sorry for the delayed reply. Tomasz Sterna wrote: > XEP-0020: Feature Negotiation > 2.2 Querying for Negotiable Features states at the end > "If that feature is negotiable, the responding entity SHOULD return an > appropriate negotiation form: > <iq type='result' [...] > The initiating entity MAY then submit a data form containing the > required information." > > My question is: How does the initiating entity submit the form?
With an IQ-set. [NOTE: XEP-0020 is wrong when it shows an IQ-get in Example 1, that should be an IQ-set -- I think this is a simple typo. For instance that's what we have in XEP-0095 and XEP-0096.] > If with another <iq type='get' [...] > it stands contrary to > 2.1 Basic Flow which states it is <iq type='result' [...] >. I don't think 2.2 contradicts 2.1. Perhaps it would help for me to add some flow diagrams and also show the example at the end of section 2.2? In 2.1 the flow is: INIT RESP | | | IQ-set w/submit | |----------------->| | IQ-result | |<-----------------| In 2.2 the flow is: INIT RESP | | | IQ-get | |----------------->| | IQ-result w/form | |<-----------------| | IQ-set w/submit | |----------------->| | IQ-result | |<-----------------| > If with <iq type='result' [...] > as in 2.1, You can't reply to an IQ-result with another IQ-result. > what is the required "id" > attribute that MUST correspond to a previous iq get/set per RFC3920. > But there was no iq get/set... to respond to. Right. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
