RE: [API] Two comments about the DDR API document

The use of namespaces sounds good to me, although anyone can misuse them too (as with integers).
Anyway, it is obvious that namespaces are semantically richer than an integer (maybe not much than a symbollic constant).

And thanks for the clarification about HTTP header extensions. I should have read RFC 2616 in more depth: sections  5.3 and 7.1 clearly say it. 

I had made myself a mess and a corrupted version of the sentence "The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient." was in my brain cache. Those fields cannot be assumed to be recognizable by the recipient... but they are obviously useful for a DDR.

Thanks for your clarifications, Rotan.

Regards,

Nacho
 


-----Mensaje original-----
De: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com]
Enviado el: jue 11/10/2007 0:24
Para: Ignacio Marin; public-ddwg@w3.org
Asunto: RE: [API] Two comments about the DDR API document
 
The problem with using integers for extensions by third parties is that you need someone to manage the process so that the numbers remain unique. Otherwise different third parties might use the same integers, and later when someone tries a mashup of the technologies, you get chaos. That's an overhead that needs to be avoided. Namespacing comes to mind as a better mechanism. A hybrid approach would be to associate the integers with namespaces (i.e. a couple). And we can then define the default namespace to be that of the DDWG, thus making the core methods and vocabulary the defaults.
 
Obviously we have to design for extensibility, but we have to ensure that the extensibility will function unmanaged.
 
Generally, I agree with you Nacho that the IdentifyBy* functions need to be more flexible.
 
As for your second point, HTTP allows for any field-name to be used, although it pre-defines the semantics of several (e.g. User-Agent). As the HTTP protocol permits additional headers, you cannot fail because the headers include some you don't recognise. The protocol requires you to treat those as "Extension Entity Headers". The protocol also requires these headers to be forwarded, though the eventual recipient is free to ignore them. So, in fact, by allowing the extension headers to be used in the DDR API, we're actually following the guidance given in RFC 2616.
 
---Rotan.

________________________________

From: public-ddwg-request@w3.org on behalf of Ignacio Marin
Sent: Wed 10/10/2007 22:58
To: public-ddwg@w3.org
Subject: [API] Two comments about the DDR API document




Hello everyone,

Here I come with two comments in order to start the discussion about the DDR API document (Editor's Draft version 1b sent by Jo [1]) so we all can make it evolve.

First comment (IdentifyBy* functions):
-------------

There are two functions in the draft called IdentifyByUAString and IdentifyByHTTPHeaders and there as been an unresolved discussion about whether both or them are necessary or not. But I think that there is a need for a more general function, taking into account that we want the DDR API to focus on the Web (we are working in a W3C WG) but never closing doors for its extension to other content adaptation.

For instance, and following the description format for DDR functions used in [1], we might propose a function like:

--------------------------------------------------------------
IdentifyByString (alternative better names are welcome!)

Inputs

    String (string)

      A string containing information allowing the identification of the browser and/or device. Its format is specified by input parameter "Format".

    Format (unsigned integer? String?)
       
        A unsigned integer (for me, but it is obviously open to discussion) declaring the format in which information is expressed in input parameter "String".

    Single (boolean - default False)

        Return only the best match if true, otherwise return a set of matches

Outputs

    Success

        Values: Exact Match Found, Found, Not Found

    Context Key

        A Context Key opaquely referencing various component types and their alternatives

Exceptions
        tbd

--------------------------------------------------------------

An example:

   idString = "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7\r\nAccept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n....";

   [success, contextKey] = IdentifyByString(idString, HTTP_HEADERS, false);

Where HTTP_HEADERS might be a symbolic constant representing the unsigned integer value of 1.

This would be the same as using IdentifyByHTTPHeaders. In fact, IdentifyByHTTPHeaders would now be a convenience function.

Another example would be a string including RTSP headers (if I want to cover content adaptation for media streaming). So the idString would have a sequence of RTSP headers in a format very similar to HTTP 1.1, but with the input parameter "Format" with a value of 2 for instance (expressed maybe by the corresponding RTSP_HEADERS symbolic constant).

One more example: we might try to identify, as said several times within this group, by IMEI. Just use a new value for "Format" (3, for instance), write the IMEI in the String input parameter... et voilá.

DDWG would only set some values for the "Format" input parameter (maybe only one is needed: for HTTP Headers) but would let the door open for extensions of the DDR API to other organizations, companies, etc. willing to deal with RTSP, IMEIs and whatever.

What do you think about this approach?

While you answer, I shall cover my second comment.

Second comment (What is an HTTP Header? O:-) ):
--------------

When we are talking about HTTP headers, being a W3C working group, we should only expect that. I mean... Should we support proprietary headers, just like HTTP_UA_PIXELS and many others?

If non standard HTTP headers are included, being a purist, anything out of the HTTP spec should make (for example) IdentifyByHTTPHeaders raise an exception.

I was just thinking out loud. I'd personally allow those HTTP "extensions", but I fear that we go on as the developers we are, and afterwards someone blames our API for not following [2]. There is a good excuse to avoid this issue: leave that subject open to implementations. Anyway, it might be good to make a comment anywhere in the DDR API doc.

Best regards,

Nacho

[1] http://www.w3.org/2005/MWI/DDWG/drafts/api/070831
[2] http://www.w3.org/Protocols/rfc2616/rfc2616.html