> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Monday, January 23, 2012 11:58 AM > To: [email protected] > Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.txt > > First, step 4 of Section 2 could be merged with (or moved right after) > step 1, as it involves the target set of the transformation and hence > is part of it. > > The example that recalls SMTP requirements for local > parts could be moved to Section 3 (BTW, the maximum length of 64 bytes > could also be mentioned, so that both truncation and encoding become > part of the transformation.) The point is that such choices logically > belong to step 1, since they are not based on the output of the > transformation of a given piece of private data.
I've already posted -06, unfortunately. I think it's better to just change "contains" to "can contain", and similarly "includes" to "can include". The specific rules for different tokens (e.g., local-parts vs. domain names) might be a little different. For example, base64 won't work universally on domain names, but base32 would. So the transformation needs to meet certain requirements, and so does the encoding. But those two requirement sets come from different places, so I prefer the partitioning as we have it. As for the length, I think we should be more general and just say there may be other constraints that also need to be observed in the replacement. > Second, Section 3 could mention that some transformations use a secret > key and thereby recover the definition of "redaction key". All or some > of the Key Management section, as well as the statement on its > reasonable length, could then be recovered. I don't think we want to get into the mechanics of various methods at all. To some extent, that's what got us into trouble in the first place, and also those issues are very well described and understood in existing documentation. We don't need to repeat any of that here. Since Stephen hasn't responded to -06 yet, I'll see if it's okay to do a -07 with the above or if we should stick with what we have. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
