<div dir="ltr">During our last F2F meeting at Amazon a couple of weeks ago canonicalization of phone numbers and email addresses came up.<div><br></div><div>This came up in the context of specifying subjects. RISC is proposed to allow emails and phone numbers to identify subjects in both SETs and also in subject add/remove API calls.</div><div><br></div><div>The first question is if the RISC profile should mandate or recommend canonicalization at all. While the obvious answer is yes, here are some reasons why this may not be necessary or could even lead to interop issues:</div><div>- both transmitters and receivers must do their own canonicalization to look up accounts based on user entered valiues</div><div>- canonicalization already done by transmitters and receivers most likely will not match exactly canonicalization required by RISC profile</div><div><br></div><div>Considering the above, it is not clear what value is canonicalization adding.</div><div><br></div><div>If the receiver for example is not canonicalizing at all, then forcing canonicalization in RISC APIs will lead interop issues (when the SET is sent with the canonical email then the receiver may not be able to look it up).</div><div><br></div><div>The second question is how to do canonicalization, this is information provided by Phil Hunt on how to canonicalize:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here are the canonicalization formats for telephone and email that the IETF has accepted before.<br>Note: this is to help specify the format of values when asking to add or remove a subject from a stream.<br>EMAIL  A String Value that is the Email addresses for a subject.  The value SHOULD be specified according to[RFC5321].<br>PHIONE_NUMBER  Phone numbers for the user.  The value SHOULD be specified according to the format defined in [RFC3966], e.g., 'tel:+1-201-555-0123'.</blockquote></div><div><br></div><div>and regarding SCIM:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">EMails<br>      Email addresses for the User.  The value SHOULD be specified<br>      according to [RFC5321].  Service providers SHOULD canonicalize the<br>      value according to [RFC5321], e.g., "<a href="mailto:bjensen@example.com">bjensen@example.com</a>" instead<br>      of "<a href="mailto:bjensen@EXAMPLE.COM">bjensen@EXAMPLE.COM</a>".  The "display" sub-attribute MAY be used<br>      to return the canonicalized representation of the email value.<br>      The "type" sub-attribute is used to provide a classification<br>      meaningful to the (human) user.  The user interface should<br>      encourage the use of basic values of "work", "home", and "other"<br>      and MAY allow additional type values to be used at the discretion<br>      of SCIM clients.<br>What is going on in SCIM is that service providers may wish to track multiple values (not just a single one).  Hence the extended text talking about home vs. work. etc.</blockquote></div><div><div><br></div><div><br></div><div>A safe way to require canonicalization could be to specify that receivers SHOULD do it (like SCIM above) and that transmitters should use the exact value that was sent by the receiver in the subject add API when constructing a SET..</div><div><br></div><div>Again, to me it is not clear what is canonicalization buying in this case.</div><div><br class="gmail-Apple-interchange-newline">Thoughts?</div></div><div><br></div><div><div><div class="gmail_signature">Marius</div></div>
</div></div>