attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content='"MSHTML 4.72.3110.7"' name=GENERATOR> </HEAD> <BODY bgColor=#ffffff style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px"> <DIV>I've added a few comments below.</DIV> <DIV><FONT style="BACKGROUND-COLOR: #ffffff">-Hugo</FONT><BR><BR>>>> "McDonald, Ira" <imcdonald@sharplabs.com> 03/02/00 10:19AM >>><BR>> [Sorry for earlier empty reply - sticky mouse]<BR>><BR>> Hi Paul,<BR>><BR>> We could certainly use 'collection' to hold the values in<BR>> 'application/ipp' encoding (that is, the URI and zero<BR>> or more of their associated metaparameters for security,<BR>> authentication, etc.).</DIV> <DIV> </DIV> <DIV>Tom is right in saying that the decision of how to represent this information in SLP and LDAP can be  made independently of how we choose to represent it in IPP.  And I think we're converging on Ira's proposal for the SLP and LDAP representation.</DIV> <DIV> </DIV> <DIV>Except ... there's real urgency in fixing the IPP definition now given the impending publication of the Set-Printer-Attribute operation.  Fixing the IPP definitions for these parallel attributes will be much harder after the "Set" operation is out (unless the current attribute threesome is marked as "Read-Only" in the spec with a note that a standard way for setting those attributes will be available in the future).</DIV> <DIV><BR>><BR>> But in SLP, LDAP, and a lot of other directory interfaces,<BR>> we need a simple string encoding (see the Subject of<BR>> this message).<BR>><BR>> In the SLP and LDAP encoding of the three original<BR>> parallel attributes, we already use the '>' (greater<BR>> than) as the URL delimiter (per RFC 2396 and advice<BR>> from Larry Masinter).<BR>><BR>> If we use 'collection' syntax in 'application/ipp',<BR>> the new combined attribute (now a collection) won't<BR>> be accessible to IPP/1.0 and IPP/1.1 existing software<BR>> (some of which IS extensible for new attributes with<BR>> simple datatypes).</DIV> <DIV> </DIV> <DIV>By pre-fixing collection attribute names we achieve the same level of interoperability with existing IPP clients as the one you imply.  Namely, the reading of a semantically opaque attributes with a known syntax.  Notice that IPP clients from the beginning have been advised to skip over unknown attribute syntaxes.  Current clients will have no harder time ignoring the 'start-of-collection' and 'end-of-collection' delimiters than ignoring the new 'xri' syntax.</DIV> <DIV> </DIV> <DIV>Again, we don't have to worry about current clients being able to set the new collection syntax because the "Set" operation is not out yet.  Hence the time-sensitive nature of making this decision real soon. </DIV> <DIV> </DIV> <DIV>> Thus, I was thinking of simple<BR>> multi-valued strings (an actual new 'xri' syntax isn't<BR>> strictly necessary for the IPP encoding), for better<BR>> interworking.</DIV> <DIV>><BR>> Cheers,<BR>> - Ira McDonald<BR>></DIV></BODY></HTML>