Hi Barry!

-----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)

Warning: External Sender - do not click links or open attachments unless you 
recognize the sender and know the content is safe.


> > ** 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.

[Roman] I agree with this assessment.  My perspective on this discussion is 
about having the ability to provide the language information, not making it 
mandatory.  I have no insight into the adoption.

Roman
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to