You're correct in that it probably won't take much time to hack
up the existing text to nail down some kind of encoding that would
be palatable to the IESG or whomever.
That is not what concerns me about IPP notification, however.
What does concern me is that no one has offered up any REAL
scenarios illustrating how IPP notification would actually work.
Sure, people have made comments to the effect of "just send an email
message". But I think we really need to walk thru multiple (not
just one) method of using IPP notification data to ensure that the
resulting facility is indeed useful as designed.
Do I have any suggestions? Not at this time...which is one reason
I suggested we defer this entire capability until the next version
of IPP.
Event notification is NOT something we want to take lightly, nor
do a half-baked job. Believe me, after spending the last 2 years
on SENSE development, it's pretty easy to hack together a "solution"
that appears to be useful, but ultimately falls short in the long
run. (That's not to say our SENSE implementation falls short,
mind you... ;-)
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Carl-Uno Manros wrote:
>
> At 06:23 PM 10/16/97 PDT, Robert Herriot wrote:
> >I just noticed that the IPP model document now has an Event Notification
> >Content attribute whose format is US-ASCII even though it is intended
> >for machine consumption.
> >
> >I am concerned about freezing this format into the standard because
> >I think that it is a mistake.
>
> Bob and others that have responded to Bob's message,
>
> My view is that it would be highly undesirable to just take out the whole
> concept of notifications, about which we have had general agreement right
> from the start of the project. Also, trying to leave out the format
> specification while keeping the attributes etc., I do not think is going to
> fly when the IESG reviews the document. Looking at the actual text that we
> are discussing, it seems that there are about 30 lines of text starting
> with line number 1752 (from the PDF version of Scott's latest draft).
> Reading through that, I think that we have most of the right semantics in
> there already, except for an inconsistent statement about the use of ASCII.
> We should not throw out the baby with the bath water!
>
> My suggestion is to rewrite the text in these 30 lines and instead create
> an additional MIME type called "application/ipp-notification", which
> contains the right language and encoding for I18N in the right places,
> building on what we currently have. This MIME type could be carried in
> SMTP, over HTTP, or other protocols.
>
> This does not seem such a major job. I do not think it would be a problem
> to work out the details within a week.
>
> Comments? Volonteers?
>
> Carl-Uno
>
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: manros@cp10.es.xerox.com