headers
midwest | 1 May 1998 06:54

Embroidery


I'll keep this brief because I know how busy you are.

Mid-West Embroidery is an embroidery company committed to unsurpassed quality, fair prices and 
quick turnaround.  

We also stand behind our work. 

We do work for major clothing mfg. as well as well as several major league ball teams.  

We also have an in house art and digitizing dept.  

If you are thinking of offering embroidered product to your customers or you are having trouble 
finding an embroidery company with your best interests in mind. Please email us at midwest <at> ipa.net 
and let us quote your next embroidery job. 

Our goal is to make you look good.
Permalink | Reply | 0 comments |
headers
Graham Klyne | 5 May 1998 19:50
Picon
Favicon

Feature algebra draft update

All,

I have today submitted an updated version of the feature algebra draft for
publication as an I-D.

I think the main outstanding issue is to decide (or decide to not decide)
whether or not there should be provision for arbitrary user- or
application- defined data types, per the previous discussion of feature
matching scenarios.

In the absence of a clear view, I propose to proceed to complete the draft
in such a way that the feature predicates can be used immediately for a
basic set of data types -- Boolean, Integer, Token (with no less-than
comparison), but leaving "gaps" in the syntax which can accept data type
extensions (e.g. extensible matching rules, per LDAP filters).

The following extract summarizes the changes and what I perceive to be
outstanding issues.

#g

1.3 Ammendment history

  00a       11-Mar-1998
            Document initially created.

  01a       05-May-1998
            Mainly-editorial revision of sections describing the
            feature types and algebra.  Added section on indicating
            preferences.  Added section describing feature predicate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 7 May 1998 16:58
Picon
Favicon

I-D ACTION:draft-ietf-conneg-feature-algebra-01.txt

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

	Title		: An algebra for describing media feature sets
	Author(s)	: G. Klyne
	Filename	: draft-ietf-conneg-feature-algebra-01.txt
	Pages		: 21
	Date		: 06-May-98
	
  A number of Internet application protocols have a need to provide
  content negotiation for the resources with which they interact [1].
  A framework for such negotiation is described in [2].  Part of this
  framework is a way to describe the range of media features which
  can be handled by the sender, recipient or document transmission
  format of a message.  A format for a vocabulary of individual media
  features and procedures for registering media features are
  presented in [3].

  This document describes an algebra which can be used to define
  feature sets which are formed from combinations and relations
  involving individual media features.  Such feature sets are used to
  describe the media feature handling capabilities of message
  senders, recipients and file formats.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-conneg-feature-algebra-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-conneg-feature-algebra-01.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 8 May 1998 13:08
Picon
Favicon

Feature algebra syntax - ommissions

Since posting the feature algebra draft, I have noted two omissions:

(1) I had intended to include some "convenience" syntax so that, for
example, one could write tests like:

  feature={f1,f2,...}  to mean  (| (feature=f1)  (feature=f2) ...
  feature=[f1-f2]      to mean  (& (feature >= f1) (feature <= f2) )

(these were noted in my presentation at the IETF, but got lost in
transcription to the draft.)

(2) I had intended to include an example in section 6.1, representing the
"match_format" clause from the Prolog-like example of section 5.2 into the
proposed syntax:

  (| (& (Px=1024) (Py=768)
        (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) )
     (& (Px=800) (Py=600)
        (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) )
     ;q=0.9
     (& (Px=640) (Py=480)
        (Rx=[72-600]) (Ry=[72-600]) (| (Rx=Ry) (Rx=2*Ry) (2*Rx=Ry) ) )
     ;q=0.8 )

This example suggests possible additional requirements for

(a) arithmetic expressions in feature comparisons (so that the half-square
aspect ration relationships can be captured), and

(b) possible use of auxiliary predicate functions, which might allow the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 8 May 1998 13:08
Picon
Favicon

Re: Senarios for feature matching

At 09:54 04/04/98 -0500, Al Gilman wrote:
>[Graham wrote about different classes of type systems, with varying
>scope and extensibility.]
>
>There is one key idea you are missing in your high-capability 
>scenarios.  This is the distribution of active code.

This is true.

>The basic continuously-expanding type vocabulary scenario is one
>where the URI for a type definition leads you to [optionally via
>a registry entry] the distribution site for the applet or applets
>that implement the methods of the class to which this type
>belongs for the cited type [in the environment of your choice].
>
>If you don't know how to evaluate relational operators such as
>'<' on TIFF grades, I can get it for your wholesale.  That is
>the scenario.

This is an interesting possibility, but I am sceptical about any solution
which depends upon active code for extension.

By which, I don't mean to exclude the use of such, just not to require it.

My feeling is that dependency of implementations on external registration
data is likely to reduce any early usefulness in the work being done here.
Users (or their message handling agents) are not always connected to the
global network, so I think at least early systems using our media features
must be capable of operating stand-alone.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 8 May 1998 19:24
Picon
Favicon

Re: Senarios for feature matching

In a previous message I wrote:

SUGGESTION: allow the use of "quality values" applied to media feature
values to define an ordering on those values.  This would lead to feature
values like:
    TIFF=M;q=0.8
    TIFF=S;q=0.2
etc.  In the absence of a q-value, or domain specific knowledge in the
application, ordering comparisons on non-numeric feature values would
return 'false'.

I also meant to add that the appropriate q-values for ordered tokens could,
or even should, be specified in the IANA registration for that feature.

#g

------------
Graham Klyne
Permalink | Reply | 1 comment |
headers
Satori | 17 May 1998 22:04

FREE ADVERTISING FOR YOUR BUSINESS


         Hi,

         Just wanted to pass along some info about a new piece of software I now
         call my "secret weapon". It's amazing! Listen to this.

         Me and hundreds of others can now reach "millions of potential customers"
         absolutely FREE! A lot of us are creating immediate "cash flow explosions"
         literally overnight!  And blowing the competition right out of the water!

         You have to check this thing out. To get some details, all you have to do
         is Email a request for more info...mailto:satoriinfo <at> hermes1.net    and you
         will recieve a return Email within a few minutes.  Simple.

         Take care.  I'll talk with you later.

         Bill
Permalink | Reply | 0 comments |
headers
Ted Hardie | 19 May 1998 01:21
Picon
Picon

Algebra draft

Graham,
	I've been working on a response to the most
recent algebra draft for the past few days, without a
lot of success.  I hope you don't mind that I'm sending
this out with some half-formed ideas in it, in the hopes
that you and the group can see past the problems I'm
encountering.
	First, let me say that I agree with the
implication in section 4.2 that we need to be dealing
with collections of feature values, rather than
individual features; it is apparent that in the real
world specific features are only available in certain
combinations and that we must be able to negotiate based
on the combinations, rather than insisting on the
component features.  I still, of course, believe that
creating a registry for individual features is vital, so
that the vocabulary by which the collections are created
is the same.  I am not sure, however, that it is
altogether wise to associate feature collections with
specific renderings, because there may well be
situations where a specific rendering is generated by a
combination of feature collections.  In the printing
context, for example, one feature collection might be
related to color and resolution (You can have black and
white at 600dpi or a 4-color print at 300dpi), while
another related to finishes and stock (You can have it
stapled or bound on white card stock or hole-punched or
bound on transparency).  You certainly could express
those combinations in terms of renderings, but doing so
would hide where the actual constraints arose, which I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 19 May 1998 12:25
Picon
Favicon

Re: Algebra draft

Ted,

Thanks for your comments...

At 16:21 18/05/98 -0700, Ted Hardie wrote:
>	First, let me say that I agree with the
>implication in section 4.2 that we need to be dealing
>with collections of feature values, rather than
>individual features; it is apparent that in the real
>world specific features are only available in certain
>combinations and that we must be able to negotiate based
>on the combinations, rather than insisting on the
>component features.  I still, of course, believe that
>creating a registry for individual features is vital, so
>that the vocabulary by which the collections are created
>is the same.

Absolutely.  That is a fu8ndamental building block.

My question would be: "should be also make provision to name feature
collections or feature sets within the same namespace?"  

>...  I am not sure, however, that it is
>altogether wise to associate feature collections with
>specific renderings, because there may well be
>situations where a specific rendering is generated by a
>combination of feature collections.

I agree and disagree...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Hardie | 27 May 1998 00:34
Picon
Picon

Registration draft issues

Those of you on the HTTP and HTTP-EXT working groups know that those
groups try to organize some of their discussions around issues lists.
Since I'd like to get our registration draft out the door as quickly
as possible, I'd like to adopt that method long enough be sure that I
have captured the current issues and proposed resolutions.  Below is a
first take.  Please send comments on proposed resolutions to the list
and suggestions for inclusion either to me or to the list.

Issue 1:  (IANA_CONSIDERATIONS)

The IESG has developed a standard set of descriptions for how
registries manage ongoing interactions with the IANA (currently in:
ftp://ftp.ietf.org/internet-drafts/draft-iesg-iana-considerations-04.txt).
We need to establish which of these management schemes we will
use.  My current proposal is to use the mailing list and "Designated
Expert" system.

Issue 2:  (ASN1)

Should we include ASN.1 identifiers as a part of the registration
procedure, and if so, who should assign them?  The current proposal is
to provide a place for the association of an ASN.1 identifier with a
registration, but not to require it.  If requested, IANA would also
provide one from its delegated space.

Issue 3: (STANDARD_MEASURES)

Should we restrict registrations to either metric or imperial
measures? Current proposal is to allow either measuring system to be
registered, but to require those registering the same thing in a
(Continue reading)

Permalink | Reply | 1 comment |

Gmane