Subject: [mile] FW: IDN issue

From: <[email-masked]>
Date: Wed, 25 Jan 2012 19:06:33 -0500

Hello Peter,

> In short, there be dragons.

Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal
here is to find a suitable cave in which to confine the dragons :-).

The place to start looking for that cave is an understanding of how NodeName is
used. The quick summary is that there are three cases:

(1) RIDPolicy class, MsgDestination=RIDSystem.

The NodeName is the destination of the RID message, so it can be required to work
in the DNS, which already has to deal with figuring out whether a U-Label is valid.
Text could be added to require that the NodeName either be used to send the RID
message via DNS lookup or that it has been looked up at some point in the past and
resolves to the IP address to which the RID message is sent.  Both of these
approaches rely on the DNS implementation to validate the U-label.

(2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource
class.

In both of these cases the IP address is the primary identifier (IncidentSource
needs additional text to state that the IP address is required - that appears to
have been overlooked).  There are a couple of options here:

a) The simplest is to prohibit NodeName usage.
b) NodeName could be required to correspond to the IP address via DNS lookup.

(3) RIDPolicy class, MsgDestination=ext-value.  This is an escape that allows
extensions to MsgDestination.  The description of this should include a "there
be dragons" warning about IDNs in NodeName.

So, the answer to the somewhat rhetorical question:

> Do IODEF/RID implementations want to sign up for all that?

Is approximately "Yes, by relying on the DNS implementation," with the addition
of a "there be dragons" warning to the MsgDestination ext-value extension text
to communicate that to designers of extensions, and a possible prohibition of
use of NodeName when the IP address is the primary identifier.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Wednesday, January 25, 2012 5:39 PM
> To: Moriarty, Kathleen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mile] IDN issue
> 
> On 1/25/12 3:06 PM, [email-masked] wrote:
> > Hello Pete, Peter, and Sean,
> 
> Howdy. :)
> 
> > The working group provided a few comments, they agree with
> > internationalization support, but would prefer to keep the RID
> > message in UTF-8.
> 
> UTF-8 is a character encoding scheme (RFC 6365). The data of a RID
> document could contain A-labels (or other text with characters only from
> the ASCII range) yet still be encoded in UTF-8. So the choice of UTF-8
> encoding for the RID document is somewhat orthogonal to the question of
> whether to use A-labels or U-labels in the domain name slot of the
> NodeName class.
> 
> > They would prefer any translation to punycode
> > happen by the DNS supporting the RID application.
> 
> That is one option, yes.
> 
> > Are you OK with
> > changing the text as follows:
> >
> > 11. Internationalization Considerations
> >
> > The Node class identifies a host or network device.  This document
> > re-uses the definition of Node from the IODEF specification
> > [RFC5070], Section 3.16.  However, that document did not clearly
> > specify whether a NodeName could be an Internationalized Domain Name
> > (IDN).  RID systems MUST treat the NodeName class as a domain name
> > slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
> > class;  if they do so, the UTF-8 representation of the domain name
> > MUST be used, i.e., all of the domain name's labels MUST be U-labels
> > expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels MUST NOT be
> > used.  A RID system can convert between A-labels and U-labels by
> > using the Punycode encoding [RFC3492] for A-labels as described in
> > the protocol specification for Internationalized Domain Names in
> > Applications [RFC5891].
> 
> Well, it's important to understand what you're signing up for when you
> say that you want to use U-labels instead of A-labels. Please consider
> the definition of U-label from RFC 5890:
> 
>    o  A "U-label" is an IDNA-valid string of Unicode characters, in
>       Normalization Form C (NFC) and including at least one non-ASCII
>       character, expressed in a standard Unicode Encoding Form (such as
>       UTF-8).  It is also subject to the constraints about permitted
>       characters that are specified in Section 4.2 of the Protocol
>       document and the rules in the Sections 2 and 3 of the Tables
>       document, the Bidi constraints in that document if it contains any
>       character from scripts that are written right to left, and the
>       symmetry constraint described immediately below.  Conversions
>       between U-labels and A-labels are performed according to the
>       "Punycode" specification [RFC3492], adding or removing the ACE
>       prefix as needed.
> 
> Notice what's entailed here...
> 
> 1. Unicode Normalization Form C (NFC):
> 
>    http://www.unicode.org/reports/tr15/tr15-31.html
> 
> 2. Constraints on permitted characters from RFC 5891:
> 
>    http://tools.ietf.org/html/rfc5891#section-4.2
> 
> 3. The property rules from RFC 5892:
> 
>    http://tools.ietf.org/html/rfc5892#section-2
>    http://tools.ietf.org/html/rfc5892#section-3
> 
> 4. The bidi constraints from RFC 5892, see also RFC 5893:
> 
>    http://tools.ietf.org/html/rfc5893
> 
> Do IODEF/RID implementations want to sign up for all that?
> 
> Furthermore, if we start accepting input strings then we might well need
> to specify mappings of the kind that are explained in RFC 5895. Notice
> the very helpful Section 3 in the latter specification:
> 
>    If you are implementing a mapping for an application or operating
>    system by using exactly the four steps in Section 2, the authors of
>    this document have a request: please don't.  We mean it.  Section 2
>    does not describe a universal mapping algorithm because, as we said,
>    there is no universally-applicable mapping algorithm.
> 
>    If you read the material in Section 2 without reading Section 1, go
>    back and carefully read all of Section 1; in many ways, Section 1 is
>    more important than Section 2.  Further, you can probably think of
>    user interface considerations that we did not list in Section 1.  If
>    you did read Section 1 but somehow decided that the algorithm in
>    Section 2 is completely correct for the intended users of your
>    application or operating system, you are probably not thinking hard
>    enough about your intended users.
> 
> In short, there be dragons.
> 
> Your life will be simpler if you say "we might get some IDNs out of the
> DNS or from somewhere else, and for our purposes we're going to assume
> that they're all A-labels because we don't want to deal directly with
> all that i18n madness, since it's just not a critical feature for RID
> itself and we're just a consumer of DNS names".
> 
> Just my centigram of silver. :)
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 13:04:52 -0700

Hi David,

> here is to find a suitable cave in which to confine the dragons :-).

Nice way to put it. And yes, the PRECIS WG is a fun place to hang out.
Speaking of which, how's that iSCSI profile of the precis framework
coming along? ;-)

> approaches rely on the DNS implementation to validate the U-label.

I think that might be fine. I see that version -09 says:

         1.  RIDSystem.  The address listed in the Node element of the
             RIDPolicy class is the next upstream RID system that will
             receive the RID message.  If NodeName element of the Node
             class is used, it contains a DNS domain name.  The
             originating RID system is required to check that this
             domain name resolves to the IP address to which the RID
             message is sent.  This check may be performed in advance of
             sending the message and the result saved for future use
             with additional RID messages.

However, the spec right now says that the domain name MUST NOT contain
A-labels:

   expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be

If the application is not checking this, how will it know whether any
A-labels have snuck in? Will it depend on its DNS resolver to return the
IDN in the appropriate format? The foregoing text implies that the RID
system will do the conversion, so it's not clear to me where the
responsibility lies (and if it's not clear to me, it might be clear to
an implementer).

And if only U-labels are permitted, then comparison proceeds using the
U-labels as input. However, if so we might need to specify mappings of
the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to
lowercase so that PRÉCIS.example.com is treated "the same" as
précis.example.com).

BUT...

Will RID systems in fact be doing such comparisons? The text from the
first paragraph quoted above indicates that RID systems will be checking
the association between a DNS domain name and an IP address, not
directly comparing DNS domain names (including IDNs). If that is true,
then we probably *don't* need to care much about comparison and any talk
of mappings is moot. Can you please verify that RID systems will be
checking the association with the IP address, rather than directly
comparing DNS domain names?

> b) NodeName could be required to correspond to the IP address via DNS lookup.

In -09 that is:

         2.  SourceOfIncident.  The Address element of the Node element
             contains the IP address of the incident source, and the
             NodeName element of the Node class is not used.  The IP
             address is used to determine the path of systems accepting
             RID communications that will be used to find the closest
             RID system to the source of an attack in which the IP
             address used by the source is believed to be valid and a
             Request message with MsgDst set to InvestigationRequest is
             used.  This is not to be confused with the IncidentSource
             class, as the defined value here is from an initial trace
             or investigation Request, not the source used in a Result
             message.

I think it's fine to use IP address here.

NOTE: you said that IncidentSource needs additional text to state that
the IP address required, but I do not see that here:

http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09

However, I think that can be added before sending this document to the
RFC Editor, or during AUTH48.

> be dragons" warning about IDNs in NodeName.

In -09 that is:

         3.  ext-value.  An escape value used to extend this attribute.
             All extensions shall specify the contents and meaning of
             the Node element of RIDPolicy.  If the NodeName element of
             Node is used by an extension, NodeName may contain an
             Internationalized Domain Name (IDN) and that IDN is
             required to satisfy the requirements in [RFC5890].  It is
             strongly recommended that RID Systems satisfy those IDN
             requirements via appropriate use of the DNS as opposed to
             implementing their own checks for these requirements.  For
             example, an extension could use both a NodeName and an IP
             address to which the NodeName resolves.  See IODEF
             [RFC5070], Section 5.1 on extensibility.

That seems slightly underspecified: what is meant by "to satisfy the
requirements in [RFC5890]" and "appropriate use of the DNS"? Does that
mean "ensuring that the IDN retrieved from the DNS consists only of
U-labels and NR-LDH labels"? If so, is that done by asking the DNS
resolver for U-labels, or is it done by actively performing a check in
the RID system itself (see above about "MUST NOT be A-labels")?

Is this something that is left for each extension to define? If so, we
should come out and say precisely that.

> use of NodeName when the IP address is the primary identifier.

I think we're getting close to reflecting that in text, but a few
clarifications would help, as would validation from the WG that this
direction is agreeable.

I realize that these are thorny issues and that folks probably just want
someone to come from on high and say "yea verily, here is the one true
path to internationalization nirvana". Unfortunately, there is no such
path, so the WG needs to weigh the costs and benefits, clearly
understand what it's doing, and then make a decision one way or the
other. We've had too many WGs (some of which I've been involved with)
just take some i18n advice without knowledge, and the results have been
less then positive.

Thanks for your patience!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 15:42:26 -0500

Hi Peter,

I'll try to respond in line below and let David fill in any gaps.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, January 26, 2012 3:05 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] FW: IDN issue

Hi David,

If the application is not checking this, how will it know whether any
A-labels have snuck in? Will it depend on its DNS resolver to return the
IDN in the appropriate format? The foregoing text implies that the RID
system will do the conversion, so it's not clear to me where the
responsibility lies (and if it's not clear to me, it might be clear to
an implementer).
_________
KMM: We state that the document must be UTF-8 compliant("The use of UTF-8 is REQUIRED").  Does that cover the checking since A-labels are not UTF-8 formatted?  Would the question be resolved by changing:
" A RID system can convert between A-labels and U-labels by "
TO: " A an application communicating via RID can convert between A-labels and U-labels by "

This would put the burden within a application associated with the API that is IODEF/RID/RID Transport.
What we care about is consistent transport so that applications can share data.  As long as the data received is the same for every implementation, we shouldn't care how they use the domain names in their application, right?
__________
And if only U-labels are permitted, then comparison proceeds using the
U-labels as input. However, if so we might need to specify mappings of
the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to
lowercase so that PRÉCIS.example.com is treated "the same" as
précis.example.com).

BUT...

_______
KMM: I see your point here.  How about the following text to make it clear that the IP address is required and the DNS name is derived from the IP address:

         1.  RIDSystem.  The IP address of the next upstream system accepting RID communications is REQUIRED and is listed in the Node element of the
             RIDPolicy class.  If NodeName element of the Node
             class is used, it contains a DNS domain name.  The
             originating RID system is required to check that this
             domain name resolves to the IP address to which the RID
             message is sent.  This check may be performed in advance of
             sending the message and the result saved for future use
             with additional RID messages. 
______

In -09 that is:

NOTE: you said that IncidentSource needs additional text to state that
the IP address required, but I do not see that here:
_____
KMM: Thanks, if we are fixing text, let's just add that now.  This one should be easy.

Proposed:
             address is REQUIRED when this option is selected.  The IP address is used to determine the path of systems accepting
_____

In -09 that is:

Is this something that is left for each extension to define? If so, we
should come out and say precisely that.
_______
KMM: The important part for RID is that we communicate and exchange messages in a way that everyone can accept and process.  Application handling for this translation, whether it be by DNS or some other mechanism, really shouldn't matter.  As long as the internationalization is handled in a way that lets us consistently exchange information, I think the real issues are solved, no?
If I add "See Section 11 of this document for
      Internationalization considerations."  Does that resolve the issue since it provides consistent guidance that enables the exchange of information?
_______

Peter
_________
Thank you for your detailed reviews!
Kathleen

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 14:23:52 -0700

On 1/26/12 1:42 PM, [email-masked] wrote:
> KMM: We state that the document must be UTF-8 compliant("The use of UTF-8 is REQUIRED").  Does that cover the checking since A-labels are not UTF-8 formatted?  

Not exactly. As I mentioned previously, the character encoding of the
RID document (e.g., as UTF-8) is distinct from the character repertoire
of information that goes in the domain name slot (here, the NodeName). A
document that has an encoding of UTF-8 can include all sorts of data
elements whose character repertoire is limited to the US-ASCII range
(e.g., this is true of IP addresses). The relevant distinction between
A-labels and U-labels is not the encoding of the RID document in which
they are included (Network Virtual Terminal [RFC5198] vs. UTF-8) but the
character repertoire (only characters in the US-ASCII range for A-labels
because of the special features of Punycode vs. any Unicode letter,
digit, or hyphen for U-labels). Naturally, in order to include a U-label
directly in a document or protocol it will need to use an encoding that
allows Unicode characters (such as UTF-8), but an A-label can be
included in a UTF-8 document just fine -- the decisions are separate.

> Would the question be resolved by changing:

I think that might be a distinction without a difference.

> This would put the burden within a application associated with the API that is IODEF/RID/RID Transport.

I see that as an integral part of the RID system, but perhaps I'm
missing something.

> What we care about is consistent transport so that applications can share data.  As long as the data received is the same for every implementation, we shouldn't care how they use the domain names i…

Unless they are making access decisions (authentication, authorization,
etc.) based on those domain names, because then they need to be compared
correctly. But if RID systems are making those decisions based on IP
address anyway, then I'm much less concerned -- perhaps even not
concerned at all.

Sure, that's fine. Then my question becomes: how exactly is the NodeName
actually used in RID systems? It's the use that drives the
internationalization considerations. If the NodeName is merely
epiphenomenal and it's the IP address that we use to get things done,
then we don't particularly care about the NodeName.

>              or investigation Request, not the source used in a Result

Looks good.

>       Internationalization considerations."  Does that resolve the issue since it provides consistent guidance that enables the exchange of information?

Yes, we want to make sure that appliations handle these matters
consistently. Pointing to Section 11 would solve that issue, as long as
we can agree on what goes in Section 11. :)

> Thank you for your detailed reviews!

I'm here for you! ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 17:30:09 -0500

Hi Peter,

> > Speaking of which, how's that iSCSI profile of the precis framework

I'm working on getting a set of four iSCSI-related drafts out of the storm WG first.
So far, it's three down, one to go, see http://datatracker.ietf.org/wg/storm/ .  Be
careful what you wish for as an AD :-).

> > responsibility lies (and if it's not clear to me, it might be clear to

At the end of the day the better answer (IMHO) is "depend on its DNS resolver".
If we can expect the DNS resolver to handle converting A-labels to U-labels in
an IDN and returning the result, the last sentence in Section 11 of the draft
can be replaced by:

        RID systems are expected to obtain an IDN meeting these requirements
        by asking a DNS resolver to return an IDN that does not contain
        A-labels (even if the input IDN contains A-labels).

** Will that work?

> > What we care about is consistent transport so that applications can
> > share data.  As long as the data received is the same for every
> > implementation, we shouldn't care how they use the domain names in
> > their application, right?
>

The NodeName in 6045-bis is not used for access decisions.  Access decisions
are specified in 6046-bis - see the other thread discussing certificates,
DNS-IDs and reference identifiers.

> > KMM: I see your point here.  How about the following text to make it clear
> > that the IP address is required and the DNS name is derived from the IP address:

[... text modification snipped ...]

> then we don't particularly care about the NodeName.

I'll have to leave that one to Kathleen (draft author); this concern also applies
to IncidentSource (below).

> > I think it's fine to use IP address here.

That's good.

> > the IP address required, but I do not see that here:

That text was added, but the diff doesn’t show enough context to indicate that the
text is in IncidentSource.  In any case, Kathleen's suggested addition of text to
say that the IP address is REQUIRED in all of the cases should make this crystal clear.

The Node in IncidentSource may contain both a domain name and an IP address.

> > KMM: The important part for RID is that we communicate and exchange messages in a way that everyone
> can accept and process.  Application handling for this translation, whether it be by DNS or some other
> mechanism, really shouldn't matter.  As long as the internationalization is handled in a way that lets
> us consistently exchange information, I think the real issues are solved, no?
> >       Internationalization considerations."  Does that resolve the issue since it provides
> consistent guidance that enables the exchange of information?
> > _______
>
> Yes, we want to make sure that applications handle these matters

Assuming that the new DNS resolver text for section 11 is ok, here's a suggested
(shorter) rewrite:

          3.  ext-value.  An escape value used to extend this attribute.
              All extensions shall specify the contents and meaning of
              the Node element of RIDPolicy.  See IODEF [RFC5070],
              Section 5.1 on extensibility. If the NodeName element of
              Node is used by an extension, NodeName may contain an
              Internationalized Domain Name (IDN); see Section 11 for
              applicable requirements. All extensions SHOULD use an IP Address
              in the Address element of the Node class as the primary means
              of Node identification.

** Does that look ok?

Thanks,
--David

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Thursday, January 26, 2012 4:24 PM
> To: Moriarty, Kathleen
> Cc: Black, David; [email-masked]; [email-masked]
> > KMM: We state that the document must be UTF-8 compliant("The use of UTF-8 is REQUIRED").  Does that
> cover the checking since A-labels are not UTF-8 formatted?
>
> > What we care about is consistent transport so that applications can share data.  As long as the data
> received is the same for every implementation, we shouldn't care how they use the domain names in
> their application, right?
>
> > KMM: I see your point here.  How about the following text to make it clear that the IP address is
> required and the DNS name is derived from the IP address:
> >
> >          1.  RIDSystem.  The IP address of the next upstream system accepting RID communications is
> REQUIRED and is listed in the Node element of the
> > http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--
> html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09
> >
> > KMM: The important part for RID is that we communicate and exchange messages in a way that everyone
> can accept and process.  Application handling for this translation, whether it be by DNS or some other
> mechanism, really shouldn't matter.  As long as the internationalization is handled in a way that lets
> us consistently exchange information, I think the real issues are solved, no?
> >       Internationalization considerations."  Does that resolve the issue since it provides
> consistent guidance that enables the exchange of information?
> > _______
>

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 17:50:41 -0500

I agree with David and will just add a couple of notes for clarification.

If this helps to solve the issues, I'll update the draft accordingly.

Thank you,
Kathleen

-----Original Message-----
From: Black, David
Sent: Thursday, January 26, 2012 5:30 PM
To: Peter Saint-Andre; Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: RE: [mile] FW: IDN issue

Hi Peter,

** Will that work?

KMM: This is true, we use digital signatures within RID for any identification of the sender.  This is tied to profile information about the other entities in the exchange.

KMM: The use cases that seem to be the concern are actually more applicable to the IODEF document.  The RID message could use IP addresses for any real checking needed.  Having the DNS is a nice thing, so we can rely on IP and have the DNS included for users to view.   This could be derived from the DNS as is currently suggested, put in the Node element for the RID message and stored locally (maybe validated on a periodic basis).  The DNS names will come more in handy with the Node instances within the IODEF document, where you will track the history of an incident and systems involved in the investigation or the incident (both are maintained in the IODEF document so it stays with the incident during the investigation as opposed to the messaging).  As Brian pointed out, we will need to deal with that as well at some point after we finish this up.

That's good.

KMM: Great, that sounds like an agreement :-)

** Does that look ok?

KMM: I think so, Peter?

Thanks,
--David

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 16:21:25 -0700

[ Pete, question for you inline ]

>         A-labels (even if the input IDN contains A-labels).

I *think* so but I am going to complete a final sanity-check with my
co-AD to be sure.

Pete: does that work for you?

> DNS-IDs and reference identifiers.

Right. Thus I am much less concerned about NodeNames here.

> to IncidentSource (below).

Based on Kathleen's answer, it's all about the certificate. So onward
and upward.

> say that the IP address is REQUIRED in all of the cases should make this crystal clear.

Agreed.

> The Node in IncidentSource may contain both a domain name and an IP address.

Yes.

>               in the Address element of the Node class as the primary means

Indeed it does.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 19:39:03 -0500

> Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels.
> Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term.

It's the entire client API.

Thanks,
--David

From: Pete Resnick [mailto:[email-masked]]
Sent: Friday, January 27, 2012 7:36 PM
To: Peter Saint-Andre
Cc: Black, David; Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] FW: IDN issue

On 1/26/12 5:21 PM, Peter Saint-Andre wrote:

 ** Will that work?

co-AD to be sure.

Hmmmm....I'm not sure I even know what that means. As far as I know, DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you mean by "resolver" the entire API which takes a name and resolves it? I think that is a novel use of the term.

pr

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 20:53:10 -0500

Pete,

Peter had suggested a tweak to the text that appears in -10, which should resolve the question.  Here is the current text (see the last sentence):

11.  Internationalization Issues

   The Node class identifies a host or network device.  This document
   re-uses the definition of Node from the IODEF specification
   [RFC5070], Section 3.16.  However, that document did not clearly
   specify whether a NodeName could be an Internationalized Domain Name
   (IDN).  RID systems MUST treat the NodeName class as a domain name
   slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
   class; if they do so, the UTF-8 representation of the domain name
   MUST be used, i.e., all of the domain name's labels MUST be U-labels
   expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
   used.  An application communicating via RID can convert between
   A-labels and U-labels by using the Punycode encoding [RFC3492] for
   A-labels as described in the protocol specification for
   Internationalized Domain Names in Applications [RFC5891].  RID
   systems are expected to obtain an IDN meeting these requirements by
   asking a DNS resolver to return an IDN that does not contain A-labels
   (even if the RID system's input to the DNS resolver contains
   A-labels).

Let me know if that works.

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 27, 2012 7:39 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mile] FW: IDN issue

Thanks,
--David

 ** Will that work?

co-AD to be sure.

pr

--

---

From: Pete Resnick <[email-masked]>
Date: Fri, 27 Jan 2012 18:35:45 -0600

On 1/26/12 5:21 PM, Peter Saint-Andre wrote:
> I*think*  so but I am going to complete a final sanity-check with my
> co-AD to be sure.
>

Hmmmm....I'm not sure I even know what that means. As far as I know, DNS 
resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do you 
mean by "resolver" the entire API which takes a name and resolves it? I 
think that is a novel use of the term.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: <[email-masked]>
Date: Mon, 30 Jan 2012 23:19:48 -0500

Thanks, Pete.  David Black had suggested that, so maybe he can help here.  I am just trying to make sure there is some way to address the concern.  The NodeName is only used since a DNS name looks nice, not for any type of verification.  They may be used in searches later if this data is stored with the incident data.  We of course want to handle internationalization.  This will matter more if we go back and correct it with IODEF than in the document under review.

Myself and others were confused on the use of a label that was not UTF-8 after saying the XML schema must be represented in UTF-8.  Apparently from one of Peter's messages, there is no need to be concerned there.  I am not an expert in this area and would like guidance so we can move beyond this issue.

Thanks,
Kathleen

From: Pete Resnick [mailto:[email-masked]]
Sent: Monday, January 30, 2012 10:23 PM
To: Moriarty, Kathleen
Cc: Black, David; [email-masked]; [email-masked]; Sean Turner
Subject: Re: [mile] FW: IDN issue

So, I've never heard of a client API of this sort referred to as a "DNS resolver", but maybe I'm just old and crusty. But I'm certainly not aware of such client APIs that actually exist and are able to "return an IDN that does not contain A-labels". If you all confirm that such APIs exist I'm fine with it, but otherwise it is the equivalent of "magic IDN pixie dust gets sprinkled here". I'll leave it to Sean to decide whether you have appropriately confirmed.

(If there are APIs involved here, I'm not quite clear on why you care that no A-labels appear in the Node class, since presumably those APIs are perfectly capable of taking A-labels along with UTF-8 U-labels and NR-LDH labels. But that seems to be what you decided on.)

pr

On 1/27/12 7:53 PM, [email-masked]<mailto:[email-masked]> wrote:
Pete,

Thanks,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, January 27, 2012 7:39 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] FW: IDN issue

Thanks,
--David

From: Pete Resnick [mailto:[email-masked]]
Sent: Friday, January 27, 2012 7:36 PM
To: Peter Saint-Andre
Cc: Black, David; Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] FW: IDN issue

 ** Will that work?

co-AD to be sure.

pr

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/%7Epresnick/>

--

---

From: Pete Resnick <[email-masked]>
Date: Mon, 30 Jan 2012 21:22:49 -0600

So, I've never heard of a client API of this sort referred to as a "DNS 
resolver", but maybe I'm just old and crusty. But I'm certainly not 
aware of such client APIs that actually exist and are able to "return an 
IDN that does not contain A-labels". If you all confirm that such APIs 
exist I'm fine with it, but otherwise it is the equivalent of "magic IDN 
pixie dust gets sprinkled here". I'll leave it to Sean to decide whether 
you have appropriately confirmed.

(If there are APIs involved here, I'm not quite clear on why you care 
that no A-labels appear in the Node class, since presumably those APIs 
are perfectly capable of taking A-labels along with UTF-8 U-labels and 
NR-LDH labels. But that seems to be what you decided on.)

pr

On 1/27/12 7:53 PM, [email-masked] wrote:
>
> Pete,
>
> Peter had suggested a tweak to the text that appears in -10, which 
> should resolve the question.  Here is the current text (see the last 
> sentence):
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of [email-masked]
> *Sent:* Friday, January 27, 2012 7:39 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [mile] FW: IDN issue
>
> > Hmmmm....I'm not sure I even know what that means. As far as I know, 
> DNS resolvers deal in A-labels or NR-LDH labels, not U-labels.
>
> > Or do you mean by "resolver" the entire API which takes a name and 
> resolves it? I think that is a novel use of the term.
>
> *From:* Pete Resnick [mailto:[email-masked]]
> *Sent:* Friday, January 27, 2012 7:36 PM
> *To:* Peter Saint-Andre
> *Cc:* Black, David; Moriarty, Kathleen; [email-masked]
> *Subject:* Re: [mile] FW: IDN issue
>
> I****think**  so but I am going to complete a final sanity-check with my
> co-AD to be sure.
>   
> Hmmmm....I'm not sure I even know what that means. As far as I know, 
> DNS resolvers deal in A-labels or NR-LDH labels, not U-labels. Or do 
> you mean by "resolver" the entire API which takes a name and resolves 
> it? I think that is a novel use of the term.
>
> pr
>
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>  <http://www.qualcomm.com/%7Epresnick/>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 31 Jan 2012 09:26:28 +0100

Hi, Kathleen, Pete, all,

Thought I'd jump in as a random guy off the street again.

It seems to me that the concern here is the last sentence:
   
   RID

which presupposes the existence of an API in the (stub?) resolver that

1. can be forced to return a U-label for a given query; or
2. that returns a U-label for a given A-label.

I have done precisely zero work with IDN support as an implementor, so I wouldn't even know where to start looking to verify that. It seems to me to be reasonable to assume such a thing exists, but I'm teaching myself C++ these days so am very, very wary of "reasonable assumption" and "API" appearing in the same sentence. Also, if you've never heard of such a thing, well, I consider that a data point right there.

However, what's important is not the existence of an API, but the existence of a clearly defined algorithm for the conversion between A-labels and U-labels. That we _do_ have. So, how about just dropping the last sentence? The relevant language is then:

... RID systems SHOULD support IDNs in the NodeName
    class; if they do so, the UTF-8 representation of the domain name
    MUST be used, i.e., all of the domain name's labels MUST be U-labels
    expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
    used.  An application communicating via RID can convert between
    A-labels and U-labels by using the Punycode encoding [RFC3492] for
    A-labels as described in the protocol specification for
    Internationalized Domain Names in Applications [RFC5891].

With respect to intent, it seems to me that NodeName (as well as Node) should contain identifiers for nodes suitable for presentation; that is (my reading of) the rationale behind the WG decision to deny the use of Punycode labels in RID documents.

Best regards,

Brian

On Jan 31, 2012, at 5:19 AM, <[email-masked]> <[email-masked]> wrote:

> Myself and others were confused on the use of a label that was not UTF-8 after saying the XML schema must be represented in UTF-8.  Apparently from one of Peter’s messages, there is no need to be concerned there.  I am not an expert in this area and would like guidance so we can move beyond this issue.
>  
> Thanks,
> Kathleen
>  
>  
> It’s the entire client API.
>  
> Thanks,
> --David
>  
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> Pete Resnick <http://www.qualcomm.com/~presnick/>

---

From: Sean Turner <[email-masked]>
Date: Tue, 31 Jan 2012 10:29:27 -0600

To resolve this please delete the last sentence.

Spt

Sent from my iPhone

On Jan 31, 2012, at 2:26 AM, Brian Trammell <[email-masked]> wrote:

> .... RID systems SHOULD support IDNs in the NodeName
> With respect to intent, it seems to me that NodeName (as well as Node) shou

---

From: <[email-masked]>
Date: Tue, 31 Jan 2012 11:32:39 -0500

Thank you.  Will this happen in Auth48 or should I post a new version?

Best regards,
Kathleen

-----Original Message-----
From: Sean Turner [mailto:[email-masked]]
Sent: Tuesday, January 31, 2012 11:29 AM
To: Brian Trammell; Moriarty, Kathleen
Cc: Pete Resnick; [email-masked]
Subject: Re: [mile] FW: IDN issue

Spt

Sent from my iPhone

On Jan 31, 2012, at 2:26 AM, Brian Trammell <[email-masked]> wrote:

> I have done precisely zero work with IDN support as an implementor, so I 
> wouldn't even know where to start looking to verify that. It seems to me to 
> be reasonable to assume such a thing exists, but I'm teaching myself C++ 
> these days so am very, very wary of "reasonable assumption" and "API" 
> appearing in the same sentence. Also, if you've never heard of such a thing, 
> well, I consider that a data point right there.
>
> However, what's important is not the existence of an API, but the existence 
> of a clearly defined algorithm for the conversion between A-labels and 
> U-labels. That we _do_ have. So, how about just dropping the last sentence? 
> The relevant language is then:

---

From: Sean Turner <[email-masked]>
Date: Tue, 31 Jan 2012 10:42:59 -0600

Please post a new version.

Sent from my iPhone