Hi everyone, While implementing and reviewing XEP-0171 (Language Translation), I noticed that the specification currently defines very limited error handling (Section 4.3 only mentions <bad-request/> and <item-not-found/>). In real-world translation service scenarios, servers frequently need to communicate various rejection reasons to clients. However, the current specification does not explicitly define them. I suggest clarifying these error conditions to ensure consistency across different implementations. These error conditions fully adhere to RFC 6120, and descriptive details can be included within the standard <text/> element: 1. Rate limiting / Server busy / Overload Condition: <resource-constraint/> (type='wait') Description: The system currently lacks the resources to service this stanza; signals the client to back off and retry later. 2. Unsupported language pair or translation engine Condition: <feature-not-implemented/> (type='cancel') Description: The request format is valid, but the service does not support the requested language combination or specified engine. 3. Text payload exceeds maximum length Condition: <not-acceptable/> (type= 'modify') Description: The text length exceeds the per-request processing limit; signals the client to truncate or split the text before retrying. 4. Source language auto-detection failed Condition: <bad-request/> (type= 'modify') Description: The input content is too ambiguous or unrecognizable; prompts the client to explicitly specify the 'source_lang' attribute and resend. 5. Content policy / safety filter violation Condition: <policy-violation/> (type='cancel') Description: The submitted content violates service operational rules or safety policies. 6. Quota exhausted / Paid subscription required Condition: <subscription-required/> (type='auth') Description: The translation quota has been exhausted, or an active subscription plan is required (RFC 6120 natively provides this condition specifically for subscription scenarios). Looking forward to your thoughts.