On 08.06.2016 15:28, Jonas Wielicki wrote:
> On <https://wiki.xmpp.org/web/Easy_Onboarding>, someone wrote
>> To allow for password recovery, something needs to be done. One
>> possibility is to ask the user for their phone number or email
>> address. However, users often mistype things, so that the
>> number/address needs to be validated during onboarding.

I think the last sentence needs to be refined to

"However, users often mistype things, so that the number/address needs
to be validated before password recovery is enabled.".

It doesn't has to be strictly during onboarding, and in fact some
services (Google, Facebook, EBay) do the validation long after the
onboarding has already happened.


> On <https://wiki.xmpp.org/web/Easy_Roster_Invitations#Open_Questions>,
> someone wrote:
>> 1. Should Romeo's client or his server implement token generation and
>> subscription approval?
>>   - A server-side implementation violates RFC6121 §3.1.3
>>   - A client-side implementation is not immediate if the user is
>>     currently offline
>>   - A client-side implementation needs to sync tokens between
>>     multiple clients
>>   - A server-side implementation needs an additional protocol for the
>>     client to request/invalidate tokens
> 
> A client-side implementation seems flaky for the reasons outlined there.
> "violation" of RFC6121 §3.1.3 is at least debatable: one could argue
> that using such a feature is "entering an agreement with the service
> provider".

Right. I think of "MUST" in specifications always with the addition
"except if nothing else has been explicitly agreed on". Of course one
should not strive for exceptions in every case. But a server-side
implementation for such tokens seems to be a good example for a sensible
case where an add-on specification, which is explicitly negotiated,
could overrule a MUST of the base specification.

- Florian

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to