Greg is on the right path, but unfortunately, its not as simple as just putting on the language attribute. You'd also need the encoding and any other information needed to internationalize displayed text. Then servers would have to do the processing to ensure the labels match. This may be as simple as comparing the tuples (label, encoding, language), but could get as complicated as normalizing to compare labels in different encodings and different languages... As you can see it gets complicated quick. DeltaV will have to specify how labels are compared for equality in order to ensure they are unique and support selecting revisions by labels. The question is, how far do we want to make server implementers go to support something that was supposed to be simple?
One option is for DeltaV to specify label encoding and matching semantics, but, as is the case for the Accept and Lanugage headers, servers are free to refuse to set labels, handle encodings, or support languages they can't handle. This would give servers room to differentiate themselves, and wouldn't hurt interoperability. I don't think putting this information in the Label header is all that different than other headers that provide similar information, as Greg suggests. And its still simpler and shorter than the If header. So I'm not that concerned about a complicated header that has to be parsed. It isn't that hard.
Are we getting close to consensus?
Greg Stein <email@example.com> Sent by: firstname.lastname@example.org
04/16/2001 05:32 PM
Subject: Re: Label header i18n, and RFC 2277
On Mon, Apr 16, 2001 at 09:24:19AM -0700, Jim Whitehead wrote:
> To resolve this issue, DeltaV needs to either:
> (a) Develop a plausible explanation for why label information is not human
> readable text.
> (b) Explain why label text, unlike all other human readable text, does not
> require language tagging.
> (c) Add a language tag to the label.
> In my opinion, choices (a) and (b) are high-risk, since they have a higher
> probability of causing the DeltaV draft to be sent back to the working group
> to resolve the i18n issues associated with labels. Choice (c) is low-risk,
> since it meets the letter and spirit of RFC 2277.
Rather than nuke the header, I propose that we take advantage of the
standard format for headers:
Label: name; language="en-us"
Note that RFC 2616, S3.10 talks about how to specify a language value.