response to Graham's comments
Bill Newman <[email protected]>
| Newsgroups | gmane.ietf.medfree |
|---|---|
| Message-ID | <[email protected]> |
Graham wrote (in two messages, which I'll respond to together) > (1) Have you seen <draft-ietf-conneg-W3C-ccpp-01.txt>? It is a discussion > document I put out in response to the W3C CC/PP working draft. I am not > wedded to the specific ideas suggested there, but I do think it gives one > view of how the W3C work and the conneg work may be related. I like the ideas there. In particular, I do think it would be good to solve the font problem, and I like the idea of being able to represent our data in XML. However, I thought (perhaps incorrectly -- I'm a IETF newbie) that since the syntax document is in last call, and since nobody is upset about it, there was consensus that we shouldn't be changing things very much. And the "indirect references" approach in the W3C CC/PP draft seems fairly strongly tied up with the solution to the font problem (using defaults) and with the use of XML. My proposal is a way of doing indirection without those things. I thought of my proposal as a little tweak to solve the one problem (indirection) that Ted Hardie volunteered me to solve. The CC/PP draft is a set of major changes that solves the indirection problem along with several other problems. I don't have a position on whether we should make major changes at this point, and I gather from your response that I may be confused about the group consensus on whether major changes are still appropriate. If we should make major changes, then I'd probably drop my proposal. > (2) For storing feature sets at a URL, the 'auxiliary predicate' construct > proposed in the '-syntax-' draft may have a part to play. One advantage of > this that I see is that it allows the retrieval mechanism (HTTP, or > whatever) and retrieval addressing (URL) to be separated from the feature > set description. (See also Larry's comment.) My first inclination would be to add this functionality to my proposal, rather than removing support for indirect feature sets as filters and replacing it with support for indirect definitions of named predicates. I would guess that the low-bandwidth people would probably be happier saying their feature set is <http://www.foo.com/conneg/137.html> than saying (model137) where <http://www.foo.com/conneg/137.html> end or (x) where <http://www.foo.com/conneg/137.html> end But I don't feel strongly about it. ------------------------------------------------------------------------------- > > 2. Although overridable defaults (as in [W3C-CCPP]) are undesirable > > because of the first point, we should try to get as many of their > > benefits as possible. In particular, if all model 137 phones > > have grey-scale displays with 100x200 resolution, > > and all of them have the capability for sound input/output, it > > should at least be possible to store that information at a web > > location and then say "I have the capabilities described at [some URL], > > *and* I have 32 Mb of RAM." (This is in distinction to the > > overridable default statement that "*except* *instead* I have > > 32 Mb of RAM.") > > My draft <draft-ietf-conneg-W3C-ccpp-01.txt> suggests another reason why a > mechanism that also allows for overridable defaults may be useful (e.g. the > "font problem"). Yes, solving the font problem would be good. I don't have any strong opinion one way or the other about whether the solution in draft-ietf-conneg-W3C-ccpp-01.txt would be good. I do note that that's a fairly major change to the algebra (the consequences of which I haven't thought through, hence my lack of an opinion), and furthermore that any solution will require a comparably major change to the algebra. I'm not that ambitious. (Also, I'd have guessed that it would be hard to make such big changes to the syntax.) ------------------------------------------------------------------------------- > > 3. It should be possible for users to prevent spoofing attacks. > > However, since foreseeable spoofing attacks would be rather > > difficult to do and would have no consequence worse than denial > > of service, features intended to prevent spoofing attacks can > > be optional and must not be a hassle for users who don't want > > to worry about them. > > I'm concerned that there may be some mixing of capability expression and > communication mechanism here. The 'conneg' framework as currently defined > says nothing about any mechanisms that may be used to communicate the > information. Anti-spoofing measures sound to me like mechanism. For use > with the capability expression, maybe some kind of authentication might be > desirable? > > This may just be a terminology thing -- I just want to be clear about the > issues being addressed here. ------------------------------------------------------------------------------- I'm not trying to say anything about the communication mechanisms either. (At least not here. I did say some things about timeouts and connection loss below.) All this point says is that if the text (as finally received, by whatever mechanism) doesn't have the right hash, it's to be rejected. I think this suffices to reduce any spoofing attack to denial of service, which is about the best we can do. > > 4. Devices which delegate transmission of feature sets or feature > > requirements should be able to detect failure due to network > > problems (e.g. failure of the server which they delegated the > > transmission to). They should be able to retry by any method > > they choose, e.g. trying again harder, trying again with > > content negotiation disabled, or trying again with explicit > > transmission of all feature sets (not using delegation). > > This really sounds like an operational mechanism issue: is it really > appropriate for 'conneg' to consider this (the work to date is intended to > be protocol-independent). I'm not sure about this. I don't much mind leaving it out -- it's sort of common sense for API design. But I thought it's something which any implementation should be able to proved, and which I (on some day when I'm wearing an application architect hat) would like to know will be provided. ------------------------------------------------------------------------------- > > 5. It is desirable to integrate this proposal with a proposal for > > registering feature sets analogous to the current proposal > > ([CONNEG-FEATURE-REG]) for registering features. > > I think maybe so. This may be subject to different interpretations? > > I would say that integration with a registration mechanism implies a basis > for having formally registered features/feature sets accessible in > "machine readable" form as well as the registration documents. Ted said something about this. I'm unclear on how this would work. Formally, it could be done in the same way that we register features. But as a practical matter, there are vastly more device feature sets than there are features. It seems as though the feature set registry would be enormous, sufficiently so that servers would not want to store it. (By contrast, I expect the feature registry to be just a kilobyte or two.) ------------------------------------------------------------------------------- > > 6. Nothing in the proposal should interfere with the ability of > > web caches to cache delegated feature set resources as they would > > cache any other resources. > > Hmmm... careful here, I think. It may be *necessary* to "interfere" with > caching mechanisms. I think the requirement is probably reasonable but may > need framing more carefully (e.g. "Nothing in the proposal should interfere > with the ability to integrate with web caches so that feature sets may be > cached as appropriate ..."). I am thinking that it may sometimes be > necessary to disallow caching. > > This is not (I think) disagreement with your main point, just suggesting > that the requirement must be stated carefully. Some capabilities may have > different or special "staleness" criteria to other resources. > > I would anticipate that well-specified cache control mechanisms would be > capable of dealing with the requirements of capabilities in this area, but > their design would IMO be outside the scope of this work. I appreciate that caching is a can of worms. As far as I can tell, we won't actually get into that can of worms with any reasonable proposal (including mine). But if any proposal does get into it (or if mine stumbles into it) I'd consider that a problem, so I thought it was worth bringing up. ------------------------------------------------------------------------------- > > 7. [open for discussion] What should be the detailed behavior > > of the protocol when the connection to the delegated feature > > set server times out? > > Again, is *this* group egtting into desigtn of *mechanism*? If so, I do > think we should keep a clear separation between mechanism and expression. > > It may be, for example, that this group designs the capability expression > framework required, and others (e.g. the W3C mobile group) design > mechanisms that use that framework. Other groups (e.g. fax, printing) may > use different mechanisms. But a common expression framework helps to unify > the capability semantics and ease gateways between the different systems. No one would be happier than me if there's consensus that we don't need to deal with this. But I thought I should bring it up rather than ignoring it and hoping no one would notice. ------------------------------------------------------------------------------- > >It should also be possible to support registered feature sets, by > >analogy with the existing facilities to support registered features. > >I'd be prepared to add this to the proposal if there is a consensus > >on the requirements for this. > > I had the impression that this idea was kind-of central to this work. But > I could be wrong. As I said above, I'm daunted by the idea of how big such a registry would be. Or are we not talking about a registry of all device models? ------------------------------------------------------------------------------- > >Before I discuss my entire proposal, let me compare my proposal to the > >functionality provided by the CC/PP proposal from the W3C [W3C-CCPP]. > >My proposal is simpler because I omit any direct support for > >overridable values. In particular, under the CC/PP proposal, the > >negotiation language is powerful enough to express such things as "I > >have the capabilities described at [some URL], *except* *instead* I have 32 > >Mb of RAM [instead of the default 16 Mb of RAM]." Under my proposal, > >this functionality is replaced by > > a. a negotiation language which is only powerful enough to express > > "I have the capabilities described at [some URL] *and* I have 32 Mb > > of RAM" (which will work only if the feature set stored at the URL > > doesn't have contradictory information about RAM); and > > I would aim for this to be an orthogonal issue. (I.e. with scope for it to > be addressed later if required.) > > > b. support for URLs decorated with "?" optional suffixes, so that > > organizations which really need to provide many options with defaults > > can implement this functionality using CGI scripts and URLs > > of the form "http://conneg-server.some-company.com/model-137?ram=32". > > I'd rather see such functionality, if required, provided within the > capability expression rather than solely through some external mechanism. Regardless of how much functionality the language provides, I think it would be good to have a consensus about how we feel about CGI feature sets. My preference would be to endorse them. Extending the language to handle defaults would be good for other reasons (esp. the font problem, which doesn't seem to be soluble by this mechanism). But there will always be someone with something not supported by the language. If we allow URLs, we should probably think about whether we'll embrace the manufacturer of a tide-powered interface wants his capability server to return a different value depending on the phase of the moon. ------------------------------------------------------------------------------- > >The URL must have a "http:" prefix. > > I would not wish to restruct URL forms at this level. I think that is > appropriate for an application profile of the capability expression > framework. http: URLs may be inappropriate in a mail environment: LDAP > or MAILCAP(?) might be more appropriate there. For Web based applications, > http: probably is appropriate. I just didn't want to require an implementation to have an ftp client, gopher client, and so forth. I agree now that it would be better to instead write "'http:' prefixes must be supported; other prefixes may be supported." ------------------------------------------------------------------------------- > > Fancy URLs with trailing "?" > >properties are explicitly allowed; this leaves an hook to allow sites > >maintaining feature set servers for devices with many configurable > >options to allow default properties to be overridden at the delegation > >server. (E.g. the model 137 could have 16 Mb RAM as an overridable > >default after all if the feature set server is sophisticated enough to > >handle URLs of the form > >"http://conneg-server.some-company.com/model-137?ram=32".) > > My suggestion (2) above allows this kind of selection without imposing > requirements on the URL form. Specifcally, the URL reference access an > environment of feature expressions -- only those that are required would > referenced by the capability expression. E.g. My intent was not to impose a requirement, just to say that it's OK if clients do this, and the protocol should deal with it gracefully, instead of telling people that do it that they're different and strange if they want to do this. And I thought it was sort of neat that by supporting it properly, a simple version of client-side default values falls out for free. (At least for free from our point of view as protocol writers -- it doesn't need to be centrally standardized in order to interoperate.) But since there doesn't seem to be any way to make the solution to the font problem (i.e. server-side default values) fall out for free, we still probably need default values in the language. ------------------------------------------------------------------------------- Thanks for all your comments! Bill