<xs:element name="human_result" type="xs:string"
minOccurs="0" maxOccurs="1">
<xs:attribute name="lang" type="xs:lang" default="EN"/>
</xs:element>
Is that what folks are looking for? If so, I'll upload another revision with
that updated in the two places it exists.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -----Original Message-----
> From: Barry Leiba <[email protected]>
> Sent: Monday, March 10, 2025 6:41 PM
> To: Roman Danyliw <[email protected]>
> Cc: Brotman, Alex <[email protected]>; The IESG <[email protected]>;
> [email protected]; [email protected]
> Subject: Re: [dmarc-ietf] Re: Roman Danyliw's Discuss on draft-ietf-dmarc-
> aggregate-reporting-28: (with DISCUSS and COMMENT)
>
> > > ** human_result. It appears that there is at least one data element
> > > (human_result per Sections 2.1.1.12 and 2.1.1.13) which is intended
> > > to be a human readable string. Per Section 4 of RFC2277 saying
> > > “protocols that transfer text MUST provide for carrying information
> > > about the language of that text”, what is the approach prescribed by
> > > this specification? Should an xs:lang attribute be added to the
> > > human_result
> element?
> >
> > I'll be honest that I don't have a preference here. Someone else
> > called this out I believe as well. If others believe it necessary, I will
> > certainly
> add it to the document.
> >
> > [Roman] In my assessment RFC2277 requires some kind of approach to
> > carry the language information. It's up to the WG, but my
> > recommendation would be to use the built-in schema data type of
> > xs:lang
>
> I'll note that 2277 goes on to say this:
>
> Note that this does NOT mean that such information must always be
> present; the requirement is that if the sender of information wishes
> to send information about the language of a text, the protocol
> provides a well-defined way to carry this information.
>
> In other words, we could add an optional xs:lang, which the sender could
> use... or
> not.
>
> I'll note that "not" is far more likely than otherwise, and, while I don't
> see an
> objection to providing the option, I can't imagine that it will result in any
> practical
> difference: I doubt we'll see changes in implementations to use it.
>
> Barry
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
