Thursday, January 26, 2006, 6:16:31 PM, James M Snell wrote:
Maybe Joe is right, and we should just give non-normative advice on the interpretation of basename, rather than restrict its syntax, but a few comments anyway: > == Proposal == > 11.2.2 The "pub:basename" Element > When posting an atom:entry to a collection in order to add a new member, > a client may include a pub:basename element. This constitutes a request > by the client that the URI assigned to the new resource incorporate the > specified path segment. The value of the pub:basename element MUST > conform to the path-rootless construction as defined in [RFC3986]. Does Atom Protocol use IRI's everywhere? If so then that should be: The value of the pub:basename element MUST conform to the ipath-rootless construction as defined in [RFC3987]. What about dot-segments? If we are banning abs_paths, should we ban them too? Eg: "/./" and "/../" > Collections MAY take the value into account when generating a new > member's URI. For example, a typical application would be an APP > server which uses dates to construct part of the URI path, e.g. > "http://example.com/pub/2006/01/10";, but which allows clients to > specify the last part of the URI path. > Implementors should note that path values consisting of multiple > segments (e.g. "pub/2006/01/10/cats") are likely not to be as widely > supported as single segment values (e.g. "cats"). Why not? As we aren't allowing duplication of the server's necessary base URI administravia, then anything the client provides is information that the client wants to appear in the URI. Given a requested basename such as: "best-of-2006/music", if the server doesn't support multi-segment suffixes, it would be better to treat the "/" the same way as any other unsupported character and replace it with a hyphen or something, effectively munging the basename into a single segment, such as "best-of-2006-music", rather than drop the initial segments, or some other fallback. > URI delimiters included in the value MUST be iterpreted as > delimiters and are not to be escaped by the server. Sorry for being pedantic, but what is a URI delimiter? Are ":", "#", and "?" URI delimiters? What does "interpreted as a delimiter mean"? If a client posts a basename with "/" in it, but the server constructs URIs of the form ?entry=blah, how should the "/" be treated as a delimiter? If the obvious interpretation is taken: "Slash characters ("/") MUST appear un-escaped", then this prevents the multi-segment munging behaviour described above; there doesn't seem to be a good reason to prohibit that. It also seems a bit strong to use a MUST, given that the basename is only supposed to be a suggestion. [PS: apologies for pointing out the use of obsolete URI terms, and then continuing to use them myself, but I'm more familiar with the old terms; I hope everyone understands what I'm trying to say.] -- Dave
