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/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
