Monday, January 30, 2006, 3:44:21 PM, Thomas Broyer wrote:
> 2006/1/30, Julian Reschke <[EMAIL PROTECTED]>: >> Thomas Broyer wrote: >> > ... >> > Well, given that "Server implementations MAY attempt to comply with >> > the request" and "Server implementations MAY modify the requested >> > string for any reason", I thought a SHOULD was enough. I don't know of >> > any, but server implementors might have good reasons not to implement >> > RFC2184 >> >> *If* there are good reasons not to implement RFC2184, then this spec has >> an I18N problem, right? > Hmm, right. > Even an implementation without any charset conversion facility (e.g. > iconv or recode) can implement RFC2184. Such an implementation would > only honnor slug-requests using known charsets, but I can't see any > reason not to implement RFC2184. > Let's go for a MUST? Sounds ok. Or alternatively we could say: The header MAY be encoded according to the RFC2184 conventions for long values or charset encodings. That way we avoid the awkwardness of applying a MUST-level requirement to a header that is permitted to be implemented arbitrarily or not at all. I support either this Pace or PaceSlugInHeader. PaceSlugInHeader is probably harder to get wrong. I'd like to see some of the proposed changes incorporated though, such as [1]. Can they be put in as editorial changes if there is support? [1] http://www.imc.org/atom-protocol/mail-archive/msg04306.html -- Dave
