Issue 259 Some alternatives, proposals

This is a multifaceted issue. 

Currently the note [1] indicates the following in Section 2.2: 

{The value and the meaning of the expectedMediaType attribute is
similar to the value allowed for the 'Accept' header defined by HTTP
1.1 specification, Section 14.1 [IETF RFC 2616] and MUST follow the
production rules defined in that section. The 'q' parameter defined by
HTTP 1.1 specification, Section 3.9 [IETF RFC 2616] is allowed, but
other accept-extensions are not allowed.
}

Schema production rules in the note were removed in favor of using
RFC2616[IETF RFC 2616] normatively to define the content of
expectedMediaType attribute. As LC 259 [2] is stated, we have some
editorial as well as design issues with respect to how the intended
value differs from what RFC2616 prescribes:

(a) The value of the expectedMediaType is not intended to contain the
prefix "Accept:" in our spec, but that is not clear.  

(b) It does not allow accept-extensions. This is related to LC260 [3]
which is discussed in thread [4]. Depending on how LC260 is resolved,
the restriction may need to be removed. 

(c) Adopting the production rules in RFC2616 [IETF RFC 2616] causes
quoted octets as part of parameter value. Currently the attribute is
defined as a xs:string and can not contain octets without introducing a
specific encoding mechanism (ouch :-)). When we evaluated the BNF in
RFC2616, we noticed that this is a side effect of adopting the
specification normatively. 

We propose the following to address a-c: 

(1) Add a restriction to the paragraph to indicate that "Accept:" prefix
is not allowed. This will resolve (a). 

(2) Use the future resolution for LC 260 [3], to remove/retain the
restriction on accept-extensions. (b)

(3) We are not sure how to address (c). Here are some choices instead of
devising an encoding mechanism, which appears to be complicated for no
good reason: 

C-1: Instead of using RFC2616, resort back to using our own production
rules as were defined by a schema. This changes a previous decision made
by the wg that removed the schema production rules from the note which
applied to the value of expectedMediaType. It allows the content to be a
string while not allowing octets. Further, it does not require special
cases for using RFC2616. Note that this option also solves (a). 

C-2: Define expectedMediaType to be xs:base64Binary, instead of
xs:string. This avoids the need for special encoding of octets if we
were to adhere to the production rules in RFC2616. 

C-3: Restrict the usage of production rules in RFC2616 to exclude quoted
octets, hence restrict the usage of production rules as to only allow
CHARs. 

It seems to me that initially octets as media-type parameter values were
not intended by the wg which we have inherited as a side effect of
referring to RFC2616. Therefore, it is not clear whether C-2 is a good
solution from that perspective or how common it is to use octets as
parameter values for a media type, i.e. 80/20 rule... Therefore, we were
not sure whether allowing the flexibility and hence choosing C-2 would
be helpful. 

The wg should entertain discussing the choices listed here. 

On a personal note, I prefer C-3 or C-1 for keeping things simple. 

Cheers, 

--umit


[1] http://www.w3.org/TR/xml-media-types/
[2]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues-c
ondensed.html#x259
[3]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues-c
ondensed.html#x260
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0008.html
[IETF RFC 2616] http://www.w3.org/Protocols/rfc2616/rfc2616.html

Received on Wednesday, 5 January 2005 23:12:43 UTC