Re: Graham's comments on feature-sets-at-urls-00

At 09:56 04/03/99 -0800, Bill Newman wrote:

>> The remainder of this message contains comments about specific portions of
>> your text:
>> 
>> >Abstract
>> >
>> >   Other Internet Drafts from the CONNEG working group describe a
>> >   syntax[SYNTAX] and vocabulary[FEATURES] for negotiating media feature
>> ................................................[---------]
>> I'd suggest "representing".  Negotiation, per se, is not covered there.
>> 
>> >   sets which can be used for transmission of a message.
>> [...]
>
>I used this terminology because I'd assumed that reducing two feature
>sets to a compatible intersection, using the algorithm described by
>the syntax document, was considered "negotiation". However, whether or
>not that is considered negotiation, nothing is lost by writing
>"representing" instead of "negotiating" here, since this extension is
>wholly about the representation.

Please see the terminology section of
<draft-ietf-conneg-requirements-01.txt> (and feel free to disagree, of
course).  I see feature matching as just *part* of a negotiation process.

>> Some observations about this syntax:
>> 
>> (a) Using the notation of RFC2234, this can be described as:
>>        filter =/ "<" absoluteURL ">" ...
>> i.e. without need to repeat other elements from [SYNTAX].
>
>I wasn't sure what's considered better style, whether detailed
>definitions should be repeated or just referenced. Either way is fine
>with me, and if there are no other comments I'd be happy change it to
>the form that you recommend.

I guess that RFC2234 is sufficiently new that a consensus on appropriate
style for use of the new elements has yet to evolve.

>> (b) this formulation syntactically binds "md5" to the URL form, and
>> prohibits other parameter values in this position.  Here is another
>> possible approach:
>>        filter    =/ "<" absoluteURL ">" *( ";" parameter )
>>        parameter =/ "md5" "=" 32*HEX
>> This would syntactically allow "md5" to be applied to any "filter", and
>> allow any other parameter (e.g. "q=") to be applied to the URL form.
>> QUESTION:  is this an appropriate approach?
>
>I'm agnostic on this one. It makes the syntax more regular, but that's
>not necessarily a good thing when the currently-defined underlying
>semantics don't have the same regularity:
>
>                           semantically  allowed      allowed 
>                           meaningful?   by your      by draft
>                                         new syntax?  syntax?
>                           ------------  -----------  --------
>    absoluteURL + md5    = yes           yes          yes
>    other filter + md5   = no            yes          no
>    absoluteURL + q      = yes*          yes          yes
>    other filter + q     = yes*          yes          yes
>                           ("yes*"="meaningful at top level only")

This is a nit, and I don't want to go to war over it.  But I can imagine
that there could be circumsances in which "other filter + md5" is
semantically useful, in that it could be used as an integrity check on a
filter, or applied to other (not-yet-defined) forms of filter.

I don't believe "absoluteURL + q" was allowed by your syntax:

      filter = "(" filtercomp ")" *( ";" parameter )
             / "<"
absoluteURL ">" *1( ";md5=" md5value )
             / "(" filtercomp *( ";"
parameter ) ")"
               "where" named-pred-sequence "end"

unless you do something like:

      (& <Absolute-URL>;md5=foo );q=0.6

As a point of principle, I think it's probably appropriate to use formal
syntax notation to define syntactic constraints, and semantic description
to define semantic constraints, so I'd vote for the regular syntax
approach.  But I'm not hung up on this.

>I'm opposed to normalization here, because I see the benefits as very
>small, and because it adds some complexity to the specification and
>implementation. To a large extent, this is probably a matter of taste,
>but I'll try to justify it nonetheless.

Fair enough:  I think that should be stated explcitly.  I don't think
justification is needed.

>We've almost reached the new millennium, and it's now routine to set
>up a clean communication channel (using some form of encapsulation if
>necessary) which doesn't mess with any of the bits in the message,
>whitespace or not. I'm not convinced that it's worthwhile to add any
>complexity to the standard in order to try to accommodate systems
>which won't do this. It adds some cost for the systems which do
>communicate cleanly, and it can't adequately address the problem of
>systems which don't communicate cleanly, since we can't anticipate all
>the ways they might corrupt the message.

In your applications, I think this is true.  Coming from a more e-mail
oriented perspective I'm less sanguine about clean channels.

>All that said, normalizing whitespace has a rather small cost (mostly
>some seldom-used code to handle quoted whitespace, I think), so my
>feelings about it are rather mild.

I'm certainly not arguing for complex semantic normalization.  My offering
proposes very simple-minded whitespace normalization.

>> >Interpretation of URLs
>> >
>> >   Any implementation of this extension MUST be able to process URLs
>> >   with an "http" scheme. Other forms of URL MAY be supported.
>> 
>> My initial response to this was "why MUST http"?  But, on reflection, I
>> accept that it is useful to have some common mechanism defined.  But I can
>> imagine cases where "http" is not appropriate to support:  this is one
>> reason that I would prefer to see the access mechanisms defined separately,
>> so that the syntax can be used without a specific mechanism for
>> applications where this is appropriate.
>
>I certainly agree that if we do choose to split this document into
>separate syntax and mechanism documents, this requirement belongs in
>the mechanism document.

That would suit me just fine!

>> In summary, I am content with this IFF it is stated separately from feature
>> set syntax extensions.
>
>I think I disagree here. This seems to me to be an appropriate
>requirement, even if we end up treating syntax extensions and
>mechanism as a single monolithic extension to the standard. As I see
>it, it's not just useful to have some common mechanism defined, it's
>vital.

I envisage deployments where http is simply not available.

>I can imagine scenarios where it's not appropriate to support "http:"
>URLs, but they're obscure scenarios.

Angonamo!  I've not argued for not supporting http: URLs.  I've only argued
for not requiring HTTP resolution in all cases.  As I type this, I do not
have a live Internet connection;  for e-mail based applications, I believe
that mechanisms that do not depend on continuous Internet connectivity are
appropriate.  I do not believe this is an "obscure" scenario.

[...]
>That is, 
>  (1) I think without a requirement like this, there's no
>      interoperability.

My view is that the resolution mechanism *requirement* should be defined as
part of the application, not as part of the media feature framework.

For example:  the media feature syntax work is referenced by Extended
Internet Fax:  it is interesting to note that all of the normative
references are contained in the master document;  the remaining documents
are cited for their technical detail, not the requirements that they impose.

>Do you have some scenario(s) in mind where this requirement would be
>more of a problem than I realize?

E-mail, Internet fax.  (And also some non-IETF work that I am involved with.)

>> >   Any implementation of this extension MUST be able to process data
>> >   returned with the MIME type "text". Other types MAY be supported.
>> 
>> Seems reasonable.
>> 
>> One thought I had was that a multipart containing human- and machine-
>> readable parts might be used (a bit like multipart/report), so that systems
>> without content negotiation could offer the user a choice.
>
>I don't understand what you're proposing here well enough to comment on it.

This is blue-sky stuff, and I'm not proposing it for immediate
consideration.  But if the URL resolves to something like this:

    multipart/media-features
        text/plain  (or   audio/xxx ?)

        (human comprehensible description of features)

        --
        text/plain

        (media feature expression)

This admits the possibility that the URL used could be used in different
ways by 'conneg' aware and other systems to obtain a description of the
media features.

[...]
>There are two channels involved, channel X from the CONNEG client to
>the CONNEG server, and channel Y from the CONNEG server to some HTTP
>server holding the feature set. 

I don't think we are in fundamental disagreement here, but I had to
double-take when I read "CONNEG client" and "CONNEG server".   I think you
are describing a very specific (but legitimate) scenario.  While I think it
is appropriate to meet the requirements of this scenario, we shouldn't
treat it as the only one.  (In your scenario, I would note that it may be
sufficient to secure just one of the channels by other means, so the
overhead of strong security can be focused on some key systems.)

#g

------------
Graham Klyne
([email protected])