2006/1/30, David Powell <[EMAIL PROTECTED]>: > > Monday, January 30, 2006, 9:49:07 AM, Thomas Broyer wrote: > > > Server implementations are more likely to be able to incorporate > > requested strings if they are constructed with sensitivity to IRI > > syntax rules [RFC3987]. In particular, strings containing characters > > with syntactic significance, in particular the path-separator > > character "/", are apt to cause server implementations difficulty. […] > I'd prefer this paragraph to be replaced with: > > Server implementations MAY modify the requested string for any > reason, including: (1) to ensure that it provides a unique IRI for > the entry, and (2) to restrict the string to an implementation- > specific set of characters.
+1 (unless someone come up with something better ;-) ) > > Servers SHOULD be prepared to process a header value encoded > > according to RFC2184 conventions for long values or charset > > encodings. > > Who is the SHOULD for the benefit of - lazy implementors who don't > want to implement RFC2184? I think that it should be a MUST. It is > either supported or it isn't, else we will have interop problems when > clients attempt to use it and find that their slugs are never getting > incorporated because using RFC2184 means that they are sending > "filename*" parameters and servers are looking for "filename". 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… I also thought about referencing RFC1806 only (RFC2183 updates it, but doesn't obsolete it)… Either way (SHOULD or MUST) will be OK for me, as I'm likely to implement RFC2184. -- Thomas Broyer
