Yup - comes down to the robustness principle. I think "SHOULD accept" is probably appropriate for anything that previously was permitted to be created. Going further, if all you're doing is comparing string stuff (- yes, related to the other part of this thread), there's no reason the RP has to actually interpret the blob or convert it to a native string type. But that may be too wordy to be worth specifying. Most of the implementations I've seen lump all the STRING types under a single implementation. They do a simple byte by byte compare to see if they match for comparison purposes so a "SHOULD accept" shouldn't be too onerous. The hard part is generally figuring out how to select the ASN1 encoding for any given input native string and that's what's getting deprecated. All of this is a long winded way of saying yes to "MUST NOT create" and "SHOULD accept" for IA5String. At 02:49 PM 11/20/2009, Stephen Kent wrote: >At 11:33 AM -0500 11/17/09, Michael StJohns wrote: >>I'd suggest that since this is a deprecation that it be MUST NOT create and SHOULD accept to deal with interop with existing systems. Just a thought. > >Mike, > >That is an interesting suggestion, i.e., to separate the requirements for CAs vs. RPs. > >The status for BMPString was the same in my before and after illustration. > >So I assume that you would suggest that we label IA5String as MUST NOT create and SHOULD accept, right? > >Steve
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.