[dnssd] comments draft-sullivan-dnssd-mdns-dns-interop-01

[Daniel Migault <[e-mail]>]

Hi Andrew,

By the way, thank you writing this document. Here are some small comments
on the draft.

BR,
Daniel

Comment 1:

"That convention is the reason behind the development of Internationalized
Domain Names for Applications (IDNA2008, [RFC5890], [RFC5891],
[RFC5892],[RFC5893], [RFC5894], [RFC5895])."

I think we should add one sentence to mention that RFC0952 was too
restrictive.  I would propose something like this:

"This convention is too restrictive and prevent many native language to use
their specific characters."


Comment 2:

"It does not restrict which Unicode code points may be used in those..."
Unicode has not been defined previously. Maybe which should clarify this by
saying that Unicode is the set of UTF-8/16/32 or simply removing Unicode
the word Unicode in the sentence. I fell that in this document Unicode is
UTF-8.

Comment 3:

"As a result, the sorts of application considerations that are appropriate
   to the general-purpose DNS name, and that resulted in the A-label/
   U-label (see below) in IDNA2008, are not the right approach for DNS-
   SD."
This is unclear to me what is behind that.

Comment 4:

1.1. Conventions and terms used in this document

I think we should also add that user is familiar with the mDNS naming
convention. Maybe that is fine now as we define the owner name of DNS-SD.

Comment 5:

2. Requirements for a profile for label interoperation

I do not see specified how a profile will operate between the two naming
convention. Regarding the current document, I would remove the word
"profile".

Comment 6:

I would move to the beginning of section 2 the text below (instead of
section3).

   DNS-SD specifies three portions of the owner name for a DNS-SD
   resource record.  These are the <Instance> portion, the <Service>
   portion, and the <Domain>.  The owner name made of these three parts
   is called the Service Instance Name.

Comment 7:

I would also provide an introduction to the section. I would probably start
section 2 with something like that:

"The goal of this section is to list requirements to ensure that a
succession of labels is appropriately considered by either a DNS resolver
or by a DNS-SD resolver. More specifically, there is not a one-to-one
matching between IDNA2008 and UTF-8 and UTF-8 contains codes that do not
belong to IDNA2008. As a result, requirements address the following goals:
1- An IDNA2008/LDH succession of labels formatted for DNS resolvers should
not be considered as UTF-8 by DNS-SD resolvers. [I think the document does
not detail that point]
2- An UTF-8 succession of label format for DNS-SD resolver should be handle
in a defined way by DNS-SD resolver when interacting with the DNS. This
requires the DNS-SD resolver to handle this succession of labels and either
convert it to an acceptable IDNA format for DNS resolvers, to handle it
independently of any DNS library, or to consider it as an opaque binary
string."


Comment 8:

   "Only some portions are implicated.  In any case, if a
   given portion is implicated, the profile will need to apply to all
   labels in that portion."

Maybe we should explain why we consider each portion individually. I
propose the following text:

Each of the portion have a specific function and is handled differently by
the resolvers For example, the Instance portion target the end user, the
Service portion the DNS-SD service itself, while the Domain portion
provides a point of attachment to the DNS architecture. As a result,
requirements for interoperability between DNS and mDNS shoudl be done on a
portion basis. Each portion may be constituted by one o multiple label, in
which case requirements apply to all the labels of the portion.


Comment 9:

Section 3.3

"The first of these is rejected because it represents a potentially
significant increase in DNS lookup traffic for no value. ..."

My understanding is that we will have multiple ways to represent a single
entity. This may also raise some security issue. (Naming collision)

Comment 10:

Could the DNS-SD resolver perform a conversion UTF-8 to IDNA. Of ccourse
this would consider some restriction on the codes used.

The document specifies U-labels cannot contain upper case letters. What is
not clear is that this is the only constraint.




-- 
Daniel Migault
Orange Labs -- Security
[phone]