Re: Issue 259 Some alternatives, proposals

C-1 seems reasonable.

On Jan 5, 2005, at 3:11 PM, Yalcinalp, Umit wrote:

>
> 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
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 6 January 2005 02:04:27 UTC