Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)
On 5/8/19 12:23 PM, Florian Schmaus wrote: > On 25.04.19 21:09, Georg Lukas wrote: >> * Kevin Smith [2019-04-17 20:28]: PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779 >>> >>> This seems a little backwards to me - it’s only saying the completely >>> non-normative 'is a good practice’ for doing the right thing, while >>> saying ’should’ (yes, I realise lower case) accept the wrong thing. >>> Should we not SHOULD doing the right thing? >> >> You've done a good job of hiding this remark (even from me), and the >> topic didn't fit into our last Council Meeting, so pulling this back up >> on the list, with a greppable subject. >> >> If you prefer to have normative value-add, I'd replace the figleaf-box >> with something akin to this strawman text: >> >> - >> The receiving client should consider the following when generating a >> Receipt, depending on the message type of the message that contained >> the Receipt Request: >> … >> >> - "error": this should not actually be possible, so the client SHOULD >> NOT (MUST NOT) respond. > > I think this is actually possible: Consider a bounced Delivery Receipt > Request where the bouncing entity followed RFC 6120 § 8.3.1. 6., i.e., > "The entity that returns an error stanza MAY include the original XML > sent…". > > I think this is a typical case where we have to break an endless cycle, > therefore it should be "MUST NOT". Agreed. Peter signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)
On 25.04.19 21:09, Georg Lukas wrote: > * Kevin Smith [2019-04-17 20:28]: >>> PR #779 - XEP-0184: add a box about types and JIDs - >>> https://github.com/xsf/xeps/pull/779 >> >> This seems a little backwards to me - it’s only saying the completely >> non-normative 'is a good practice’ for doing the right thing, while >> saying ’should’ (yes, I realise lower case) accept the wrong thing. >> Should we not SHOULD doing the right thing? > > You've done a good job of hiding this remark (even from me), and the > topic didn't fit into our last Council Meeting, so pulling this back up > on the list, with a greppable subject. > > If you prefer to have normative value-add, I'd replace the figleaf-box > with something akin to this strawman text: > > - > The receiving client should consider the following when generating a > Receipt, depending on the message type of the message that contained > the Receipt Request: > … > > - "error": this should not actually be possible, so the client SHOULD > NOT (MUST NOT) respond. I think this is actually possible: Consider a bounced Delivery Receipt Request where the bouncing entity followed RFC 6120 § 8.3.1. 6., i.e., "The entity that returns an error stanza MAY include the original XML sent…". I think this is a typical case where we have to break an endless cycle, therefore it should be "MUST NOT". - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)
On 5/8/19 9:27 AM, Jonas Schäfer wrote: > On Donnerstag, 25. April 2019 21:09:04 CEST Georg Lukas wrote: >> * Kevin Smith [2019-04-17 20:28]: PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779> >>> This seems a little backwards to me - it’s only saying the completely >>> non-normative 'is a good practice’ for doing the right thing, while >>> saying ’should’ (yes, I realise lower case) accept the wrong thing. >>> Should we not SHOULD doing the right thing? >> >> You've done a good job of hiding this remark (even from me), and the >> topic didn't fit into our last Council Meeting, so pulling this back up >> on the list, with a greppable subject. >> >> The rationale for #779 was not to change normative language while >> providing additional value to new developers. >> >> If you prefer to have normative value-add, I'd replace the figleaf-box >> with something akin to this strawman text: >> >> - >> The receiving client should consider the following when generating a >> Receipt, depending on the message type of the message that contained >> the Receipt Request: >> >> - "chat", "normal": the Receipt message SHOULD have the same @type as >> the Request message. >> >> - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A >> client choosing to respond despite of this SHOULD send the Receipt >> with type="groupchat" to the bare JID of the room and not to the full >> JID of the sender. It MAY be useful to limit this feature to private >> MUCs with a small number of participants, or to instead send the >> Receipt as a MUC-PM. >> >> - "headline": the Receipt message SHOULD have type="normal". >> >> - "error": this should not actually be possible, so the client SHOULD >> NOT (MUST NOT) respond. >> >> A client MUST be able to Process a Receipt message with a different type >> than the original Receipt Request message. >> - >> >> However, this is obviously a normative language change to a Draft XEP >> and so I didn't dare to do it, initially. > > This sounds good to me, except for the rule for "headline". I have no idea > whether that’s good or bad. The 'headline' rule seems fine to me. Peter signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0184: normative message @type rules (Was: Council Voting Summary 2019-04-14)
On Donnerstag, 25. April 2019 21:09:04 CEST Georg Lukas wrote: > * Kevin Smith [2019-04-17 20:28]: > > > PR #779 - XEP-0184: add a box about types and JIDs - > > > https://github.com/xsf/xeps/pull/779> > > This seems a little backwards to me - it’s only saying the completely > > non-normative 'is a good practice’ for doing the right thing, while > > saying ’should’ (yes, I realise lower case) accept the wrong thing. > > Should we not SHOULD doing the right thing? > > You've done a good job of hiding this remark (even from me), and the > topic didn't fit into our last Council Meeting, so pulling this back up > on the list, with a greppable subject. > > The rationale for #779 was not to change normative language while > providing additional value to new developers. > > If you prefer to have normative value-add, I'd replace the figleaf-box > with something akin to this strawman text: > > - > The receiving client should consider the following when generating a > Receipt, depending on the message type of the message that contained > the Receipt Request: > > - "chat", "normal": the Receipt message SHOULD have the same @type as > the Request message. > > - "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A > client choosing to respond despite of this SHOULD send the Receipt > with type="groupchat" to the bare JID of the room and not to the full > JID of the sender. It MAY be useful to limit this feature to private > MUCs with a small number of participants, or to instead send the > Receipt as a MUC-PM. > > - "headline": the Receipt message SHOULD have type="normal". > > - "error": this should not actually be possible, so the client SHOULD > NOT (MUST NOT) respond. > > A client MUST be able to Process a Receipt message with a different type > than the original Receipt Request message. > - > > However, this is obviously a normative language change to a Draft XEP > and so I didn't dare to do it, initially. This sounds good to me, except for the rule for "headline". I have no idea whether that’s good or bad. In other words, I’m fine with the proposed wording far enough that I think it should be proposed as an item to vote on (and I’m tending strongly towards +1). kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
