Hi David-san Thank you for your comment. I have updated the mappings document to reflect comments received form you.
There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-mappings-07 Regards, Nemo On 2014/02/10, at 23:41, "Black, David" <[email protected]> wrote: > I agree with Peter. For (1), the double-mapping behavior (local case > mapping then PRECIS case mapping) for German eszett that occurred with > the old approach was both subtle and non-obvious because it was spread > across two drafts. The new approach documents this behavior completely > in the mappings draft, which is a welcome clarity improvement. > > Thanks, > --David > > >> -----Original Message----- >> From: precis [mailto:[email protected]] On Behalf Of Peter Saint-Andre >> Sent: Wednesday, February 05, 2014 7:41 PM >> To: Takahiro Nemoto; [email protected] >> Subject: Re: [precis] Fwd: I-D Action: draft-ietf-precis-mappings-06.txt >> >> On 2/5/14, 7:17 AM, Takahiro Nemoto wrote: >>> Dear all, >>> >>> Peter-san, Alexey-san, thank you for your quick response. >>> >>> If you have any comments for open issues in mappings-06, I would like to >>> hear about it. >>> These comments will be reflected on the updated mappings document as -07 >>> before cut off date(2/14), >>> as it will influence the framework document. >>> >>> There are two points that have not reached a consensus in the mappings >>> document . >>> >>> (1) Define local case mapping as an alternative to case mapping in the >>> PRECIS framework >>> pros: German eszett, Turkish dotless i, etc. will not be mapped contrary >>> to the users' expectation. >>> cons: It is necessary to modify the framework document. >>> >>> options: >>> (A) Support the change of -06 >>> (B) Don't support the change of -06, and restore the algorithm of -05 >> >> I think -06 is fine, so I support (A). >> >>> (2) Way to deal with the context dependent mapping for both Greek sigma and >>> final sigma. >>> (a) Define extra mapping table for sigma and final sigma inside mappings >>> document >>> pros: Sigma and final sigma will not be mapped contrary to users' >>> expectation. >>> cons: It will be necessary to update this document to follow unicode's >>> updated version. >>> >>> (b) Leave it to unicode's definition >>> pros: It is not necessary to define extra mapping table for sigma and final >>> sigma. >>> cons: Unless unicode is updated and a new definition to map both sigma and >>> final sigma**has been added, >>> final sigma will be mapped to sigma. >>> >>> options: >>> (A) Support the above (a) >>> (B) Support the above (b) >>> >>> I would appreciate your comment. >> >> I support (B). >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> _______________________________________________ >> precis mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/precis > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
