Subject: [precis] mappings

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Apr 2013 15:18:09 -0600

As promised at IETF 86 (and probably IETF 85!), I've reviewed the
issues raised by draft-ietf-precis-mappings. I will also send some
editorial feedback directly to the authors of that document.

1. Width mapping has now been moved to the framework document, so I
think Section 2 and Section 3 of the mappings document can be removed.

2. I think it would be helpful to mention some examples of delimiters
other than FULL STOP.

3. This text is a bit confusing:

   One of the most useful case of delimiter mapping is when FULL STOP
   character (U+002E) is a delimiter as well as domain name.

I am not a DNS expert, but my understanding is that FULL STOP is not
part of the domain name but is a delimiter between the labels of a
domain name. I think the sentence quoted above means that in certain
protocols FULL STOP is used as a delimiter within protocol strings (such
as identifiers) in addition to being used as a delimiter between domain
name labels.

4. I think we can just mention RFCs 3748, 4013, 4314, and 4518 in
Section 4.2 and then remove Appendix B, since it is the responsibility
of other specifications to actually define the special mappings (e.g.,
this is done in draft-ietf-precis-saslprepbis).

5. I think Appendix C could be moved into Section 4.3.

6. The big open issue here is the order of mappings. RFC 5895 defines an
order of case mapping, width mapping, NFC, and the IDNA protocol. I'm
not sure why we would do width mapping before case mapping in PRECIS,
because we want to do local case mapping before non-locale-specific case
mapping. Therefore I suggest the following order:

   1. Width mapping
   2. Additional mappings (draft-ietf-precis-mappings)
      a. delimiter mapping
      b. special mapping
      c. local case mapping
   3. Case mapping (i.e., non-local-specific)
   4. Normalization
   5. PRECIS protocol

Does anyone see a reason to move width mapping after case mapping (as in
RFC 5895)?

For the record, I think we need to specify the order of operations in
both draft-ietf-precis-mappings and draft-ietf-precis-framework so that
there is no ambiguity. Once we have consensus, I will be happy to update
the framework accordingly.

Peter

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Apr 2013 22:32:08 -0400

> as identifiers) in addition to being used as a delimiter between domain

I think this feedback is right, but just so that we're clear, it's
much worse than the above in DNS names.

The dot in a DNS name is not part of the protocol _at all_.  In the
wire format, labels are delimited conceptually as follows:

	3www7example3com0NULL

It is only in the presentation format that we use dots as separators.
Moreover, we usually but not always leave off the final dot for
presentation purposes.  So you _can't_ internationalize the protocol
separator in the DNS, because it isn't there in the protocol.  It's
only there when humans look at it.  (Schroedinger's separator?)

This set of issues, which is quite unusual (perhaps unique to DNS), is
also why DNS and IDNA are only a weak model for what should be done
in other cases.  

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 13 Apr 2013 10:59:24 +0800

> also why DNS and IDNA are only a weak model for what should be done

This is btw one of the things that is much more clear in IDNA2008 than in IDNA2003.

   Patrik

---

From: Takahiro Nemoto <[email-masked]>
Date: Fri, 26 Apr 2013 10:50:34 +0900

Hi, Peter-san, I'm so sorry for my late reply.
And thank you for your review. Yoneya-san and I discussed your comments.
Our comments inline.

> think Section 2 and Section 3 of the mappings document can be removed.
We agree.

> 2. I think it would be helpful to mention some examples of delimiters
We are supposing delimiter mapping for width compatible characters 
that like '@' in mail address and ':' or '/' in URI. Even though it may be non-existent as for now, 
but I'm thinking that in the future there may be protocols that use '+', '-', '<' or '>' as delimiters.

> as identifiers) in addition to being used as a delimiter between domain
That's right. There is no FULL STOP in DNS packet.
But when comparing domain name strings outside of DNS protocol, 
FULL STOPs are used as delimiters and width problem should be considered.

For example, in web browser, FULL STOPs are considered when 
inputting words in comparing them with the page history list.

> this is done in draft-ietf-precis-saslprepbis).
We agree.

> 5. I think Appendix C could be moved into Section 4.3.
Because we thought that it's not proper to move a table 
that has a unicode version dependency in the section, 
we place in the Appendix.

> Does anyone see a reason to move width mapping after case mapping (as in
We agree about this order.

> the framework accordingly.
We will, too :-)

Best regards,
Nemo

--
Takahiro Nemoto
[email-masked]

> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Apr 2013 20:00:39 -0600

Thanks for your reply. I provide a few more comments inline (removing
areas where we have agreement).

On 4/25/13 7:50 PM, Takahiro Nemoto wrote:
> 
> On 2013/04/13, at 6:18, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:

> '-', '<' or '>' as delimiters.

OK. Do you think it would be helpful to mention examples other than FULL
STOP?

> inputting words in comparing them with the page history list.

Agreed. I think it would be good to mention that example in the text.

> we place in the Appendix.

That seems reasonable.

> We agree about this order.

Great! I'll update the framework specification accordingly.

>> the framework accordingly.

Excellent. That will enable us to close one of the only open issues with
the framework. :-)

Peter