RE: ietf-medfree mailing list

It is unfortunate that the IETF name for the WG has remained CONNEG
and the mailing list (and web site) changed its name to MEDFREE,
though. 

-d

Charter, timeline, and goals

Welcome to the ietf-medfree mailing list.  If you were previously on
the "conneg" mailing list, you have been moved over automatically; if
that is not what you want, please send a message to
ietf-medfree-request <at> imc.org with "unsubscribe" in the body of the
message.  I want to thank everyone for the participation in the
"conneg" lists to date, and I encourage those just joining the
discussion to read the archives of the exchanges so far.

As most of you have seen, the IESG has chartered this working group
within the Applications area of the IETF.  The official charter is at

http://www.ietf.org/html.charters/conneg-charter.html

Yes, the working group is named conneg and the mailing lists are
medfree.  I know it's confusing, but let's not waste any energy on
it.  The key thing is that the charter has a *very* aggressive
timeline, and we are going to have to work very hard to meet it.

The first item on our list is the registration document.  The current
draft of that is draft-ietf-http-feature-reg-03.txt available at:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-feature-reg-03.txt

Among the key elements we need to consider before a last call are:

If we are incorporating some features by reference to other
registries, (such as the Printer MIB) how are those features
referenced and incorporated into the registry?

Can we eliminate one or more of these trees?  In particular, do we

Now we are (med)free

Just a quick test and a question,

Now we have an official MedFree working group and mailing list, will
signups to the old mailing list be automatically transferred?

GK.
---

------------
Graham Klyne

Re: Now we are (med)free

Yes.  If you are on the conneg mailing list, you are on the
med-free mailing list.
	      	regards,
			Ted Hardie

On Feb 19,  1:23pm, Graham Klyne wrote:
> Subject: Now we are (med)free
> Just a quick test and a question,
>
> Now we have an official MedFree working group and mailing list, will
> signups to the old mailing list be automatically transferred?
>
> GK.
> ---
>
> ------------
> Graham Klyne
>-- End of excerpt from Graham Klyne

Comments on registration draft

Ted Hardie:
>
>
>The first item on our list is the registration document.  The current
>draft of that is draft-ietf-http-feature-reg-03.txt available at:
> 
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-feature-reg-03.txt
>
>Among the key elements we need to consider before a last call are:
> 
>If we are incorporating some features by reference to other
>registries, (such as the Printer MIB) how are those features
>referenced and incorporated into the registry?

Presumably, the filled-in feature tag registration template which sits
in the registry would contain a reference to the printer MIB
registry.  This would work fine if the printer MIB registry is used to
register values of the tag.

Now, in a scenario where you want to have a feature tag pop up
`automatically' in the feature tag registry whenever something gets
added to the printer MIB registry, we may have a problem.  I don't
know if you would actually ever want such a thing: could you give an
example?  I think that case could be handled by a special `feature tag
prefix' registration template, in which one could define the meaning
of all tags starting with `w.printer-MIB.' by pointing to an external
registry, or something.

>Can we eliminate one or more of these trees?  In particular, do we
>really need both a URL tree and a local tree? 

Re: Comments on registration draft

>>If we are incorporating some features by reference to other
>>registries, (such as the Printer MIB) how are those features
>>referenced and incorporated into the registry?
>
>Presumably, the filled-in feature tag registration template which sits
>in the registry would contain a reference to the printer MIB
>registry.  This would work fine if the printer MIB registry is used to
>register values of the tag.
>
>Now, in a scenario where you want to have a feature tag pop up
>`automatically' in the feature tag registry whenever something gets
>added to the printer MIB registry, we may have a problem.  I don't
>know if you would actually ever want such a thing: could you give an
>example?  I think that case could be handled by a special `feature tag
>prefix' registration template, in which one could define the meaning
>of all tags starting with `w.printer-MIB.' by pointing to an external
>registry, or something.

Unless there's a more compelling reason, let's not.

>>Can we eliminate one or more of these trees?  In particular, do we
>>really need both a URL tree and a local tree? 
>
>I suspect we need both URL and local; not everybody has the ability to
>allocate short URLs, and in some negotiation situations a short tag
>may be vital for efficiency reasons, or imagined efficiency reasons
>which turn into a political reasons.

ditto. Unless there's a compelling reason for having a 'local' tree, let's leave
it out.

Comments on draft-ietf-http-feature-reg-03.txt

A belated review of the feature registration draft -- most of my comments
are editorial but I do also wish to make some suggestions regarding the
nature of registered feature tags...

GK.
---

1 Introduction

   Recent Internet applications, such as the World Wide Web, tie
   together a great diversity in data formats, client and server
   platforms, and communities.  This has created a need for various
   kinds of negotiation mechanisms, which tailor the data which is
   exchanged, or the exchange process itself, to the capabilities and
   preferences of the parties involved.

   Extensible negotiation mechanisms need a vocabulary to identify
   various things which can be negotiated on.  To promote
   interoperability, a registration process is needed to ensure that
   that this vocabulary, which can be shared between negotiation
   mechanisms, is developed in an orderly, well-specified, and public
   manner.

>>>
I think this focusses too much on negotiation rather than feature
identification.  This might be softened by adition of the following text:

   Use of the vocabulary need not be restricted to negotiation: it
   might also be used to identify availability of content features
   that are not subject to negotiation.

[Fwd: I-D ACTION:draft-ietf-fax-mdn-features-00.txt]

gmane.ietf.medfree

From: gmane.ietf.medfree <Internet-Drafts <at> ns.ietf.org>
Subject: I-D ACTION:draft-ietf-fax-mdn-features-00.txt
Date: 1998-03-03 13:59:12 GMT

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Fax Working Group of the IETF.

	Title           : Using Message Disposition Notifications to
			  Indicate Supported Features
	Author(s)	: D. Wing
	Filename	: draft-ietf-fax-mdn-features-00.txt
	Pages		: 6
	Date		: 02-Mar-98
	
This document describes Message Disposition Notifications [MDN] is
   used to send the supported features of a user's Mail User Agent.  The
   original sender can use this information to send enhanced messages to
   the recipient.

   Features might indicate which formats the Mail User Agent can
   present to the user as MIME types, or finer gradations of features
   such as resolution or maximum image size.

   Features are registered using the framework described in [FEATURES].

Another comment on draft-ietf-http-feature-reg-03.txt

It has occurred to me that it would be a good idea for feature registration
to associate both a textual name *and* an ASN.1 object identifier with each
registered media feature.  This would, I believe, help to make life easier
for feature data to be carried in both text- and binary-message protocols
(e.g. HTTP/SMTP and LDAP/SNMP).

GK.
---

------------
Graham Klyne