Hi,
I’ve updated my PRECIS Java library to the new RFCs 8264, 8265 and 8266.
You can find it on Maven Central:
rocks.xmpp
precis
1.0.0
https://bitbucket.org/sco0ter/precis
Changes:
- use toLowerCase() for case mapping
- ensure that methods are idempotent
- added toComparableString() method,
ely defensive.
>
>
> On Sat, Dec 9, 2017 at 2:27 PM, Christian Schudt
> wrote:
>> Great, thanks! These code points revealed some bugs :-). They should have
>> been included in the Examples.
>>
>> Are there any known code points for the IdentifierClass / User
uot;\u00a8"
> "\u02dc"
>
>
> On Sat, Dec 9, 2017 at 8:37 AM, Christian Schudt
> wrote:
>> Hi,
>>
>> RFC 8264 introduced these new sentences:
>>
>> under certain circumstances, such as when Unicode
>> Normalization Form K
Hi,
RFC 8264 introduced these new sentences:
under certain circumstances, such as when Unicode
Normalization Form KC is used, performing Unicode normalization after
case mapping can still yield uppercase characters for certain code
points
Therefore, an implementation SHOULD apply
>
> Sigh.
>
> I'm sorry that we failed to make things clear and consistent.
>
> I agree with Bill that implementations should follow the order of rules
> in Section 7 of RFC 8264.
>
> Let me think about how we can clarify things. That might involve filing
> an erratum against RFC 8265.
>
> Pe
Hi all,
now that the new RFC 8264 / 8265 are out, I wanted to update my implementation,
which was based on the older RFCs.
Unfortunately the order of rules still confuses me.
During enforcement and comparison of a string, do I first validate a string,
then apply the rules (as written in
https
Hi,
let me raise one concern, which I had while implementing RFC 7564 and 7613.
I’ve raised it already on this mailing list, but it got no attention.
Instead of changing RFC 7564 §7 from MUST to SHOULD, why not changing RFC 7613
§3.2.2 (and likely other Enforcement sections) to stick to the ord
8 SE).
Java uses huge Unicode arrays internally to lookup the code point, I doubt that
there’s much room for optimization and even if, probably nobody cares when
saving a few nano seconds.
— Christian
> Am 23.12.2015 um 03:04 schrieb Sam Whited :
>
> On Mon, Dec 21, 2015 at 4:08 PM,
> Am 22.12.2015 um 01:50 schrieb Sam Whited :
>
> Another quick note:
>
> In your case folding
> (https://bitbucket.org/sco0ter/precis/src/ecd82b75f3611dcb37ee0fd8890bfaf02b5caf9f/src/main/java/rocks/xmpp/precis/PrecisProfile.java?at=master&fileviewer=file-view-default#PrecisProfile.java-511),
>
> Am 21.12.2015 um 22:05 schrieb Tom Worster :
>
> To what extent do you think we could combine our efforts on unit tests?
> Standard (or at least shared) test vectors would really help, given how hard
> it is for programers to decode the RFC texts.
>
Well… if there’s some XML (or other langu
> I'm curious, what made you decide to calculate the derived properties
> on prepare instead of precomputing them? Have you done any
> benchmarking of this? I'd love to see the performance difference
> between this way and pre-computing a big trie or something of derived
> properties.
Thanks for
Dear all,
I’ve been working on an open source Java implementation for the Precis
framework since a few weeks and I'd finally like to share it with you:
https://bitbucket.org/sco0ter/precis
It supports the core Precis framework (RFC 7564), as well as the username and
opaque string profiles (RFC
Anybody has a clue about this? Thanks.
> Am 21.11.2015 um 14:12 schrieb Christian Schudt :
>
> Hi,
>
> can you please help answering the following question:
>
> When doing enforcement of a string of the UsernameCaseMappedProfile as per
> RFC 7613 § 3.2.2 and th
Hi,
can you please help answering the following question:
When doing enforcement of a string of the UsernameCaseMappedProfile as per RFC
7613 § 3.2.2 and the string contains U+212B (ANGSTROM SIGN), I would first do
the preparation and it would be disallowed by the IdentifierClass because it
ha
14 matches
Mail list logo
