This reflects a problem that has come up with a proposed feature in
USEFOR, but it arises out of the syntax of MIME.
Perhaps I'm missing something, but I see no problem here whatsoever.
Currently, various MIME headers (and some new USEFOR headers) can have
parameters of the form
attribute = value
where
attribute = token
value = token / quoted-string
There is provision for new parameters to be defined in later standards,
and registered with IANA. Typically, the "values" involved are things like
charsets and filenames.
Actually, an incredible variety of stuff has been placed in parameter values in
practice. Email addresses. Quoted strings. Extremely long strings. Strings
containing control characters. Strings in different charsets. MIME already
provides complete facilities for all of this.
Now suppose someone invents a parameter where the "value" is to be a
mailbox (I don't think that case has arisen yet in MIME, but it well
might).
It arose years ago. The obvious example is filenames.
Perhaps something like:
"sender" "=" mailbox
Obviously, the mailbox has to be a quoted-string (it contains an '@',
which is a tspecial). BUT a mailbox can itself contain a quoted-string in
many situations, so one might want to write
but, of course, you can't write that because it contains nested
quoted-strings.
Sure you can. The quoting facility in content type parameters is completely
general.
So what is the proper way to do it?
Would it be
sender = "\"John D. Bloggs\" <jdbloggs(_at_)example(_dot_)com>"
Yup. And as Cyrus points out, even more complex nestings like
sender = "\"John D. \\\"Cool\\\" Bloggs"
<jdbloggs(_at_)example(_dot_)com>"
are allowed.
in which case would/should the inner \"John D. Bloggs\" then be
interpreted as a quoted-string?
It isn't a question of interpretation. The process of extraction of the
parameter value produces the result
"John D. Bloggs"
There is no wiggle room here. However, how this result is interpreted or used
is entirely dependent on the semantics of the parameter itself. If those
semantics say that quotes in the value imply a quoted string, such as the case
of a parameter value containing an email address, so be it. But it may be that
the semantics don't imply that, such as in the case of a filename, which is
fine too.
Or is it the case that there is no proper way to express this sort of
thing?
Again, the facility is completely general.
Ned