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. This comment applies to Tim's proposal too: I don't like this paragraph. I don't care how "difficult" the implementation finds it, I just want to know whether my request will succeed or fail. I don't think that there is any reason for a server to actually fail with an error if it encounters slashes, spaces, or anything else in this field. This paragraph suggests to me that a typical behaviour might be for the server to reject the entry because of the slug, and I don't think that that is desirable. 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. Of course servers may still reject entries for whatever reason, but I don't think that we should be encouraging that behaviour in this case. > 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". -- Dave
