[Standards] request for reviews: XEP-0045 v1.25rc5

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 19 18:12:39 UTC 2011

On 9/6/11 8:17 AM, Ralph Meijer wrote:
> On Tue, 2011-09-06 at 15:37 +0200, Alexander Holler wrote:
>> Am 06.09.2011 11:09, schrieb Ralph Meijer:
>>> On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote:
>>>> [..]
>>>> I don't see any reason why the user should send a form to the server.
>>>> If using a form is wanted, the correct way would be that the user
>>>> requests a form for the request from the server, and sends back the
>>>> result, which is then processed by the server (resulting in a form for
>>>> the moderator).
>>>> The described way where the user generates a form only makes sense, if
>>>> that form is forwarded to the moderator. But that would result in the
>>>> possible problems I've described (e.g. hidden fields and wrong labels).
>>> I don't see how requesting a form from the service first somehow makes
>>> this better. An attacker could simply ignore that form and submit its
>>> own bad one.
>> Whats the point that the user sends labels?
>> Where do the user gets the list of required fields from?
> Ah, these are valid concerns. Looking into it in more detail, of course
> the form for requesting voice, as shown in example 74 of XEP-0045
> v1.25rc5, is of type 'submit'. The form sent to the moderator for
> approval, as shown in example 103 is of type 'form', as at should be.
> The latter is thus an entirely different one, with additional fields
> muc#jid, muc#roomnick and muc#request_allow, constructed by the MUC
> service.
> You are taking the associated prose, that suggests to 'forward the
> request', too literal.
> The form sent by the user's client can be entirely constructed by the
> client, without displaying it as such to the user. As it is of type
> 'submit', no labels are required. The required field is 'muc#role' and
> the value is 'participant'. The type and label attributes should
> probably be removed from the example.
> Even thought this is currently not specified, future extensions could
> define how an interaction might be, with additional fields required of
> the user. Your suggestion of first requesting a form to get these fields
> (as with registering a nick or configuring a room) seems the obvious
> solution to that. If there is no immediate need for this, I suggest we
> leave things as is, though.

I've reworded those sections to remove the ambiguity.

Section 7.13

The service then proceeds as described in the Approving Voice Requests
section of this document.

Section 8.6

As noted in the Requesting Voice section of this document, an occupant
requests voice by sending a voice request data form to the service. The
service then SHOULD use that voice request data form as the basis for a
voice approval data form that it generates and sends to the room
moderator(s). The voice approval data form is contained in a <message/>
stanza, as shown below.


More information about the Standards mailing list