RE: XML Messaging Data Items

[David Burdett <david.burdett@commerceone.com>]

Paul

See comments below, marked with ##

David

-----Original Message-----
From: Paul Ulrich [mailto:paul_ulrich@hotmail.com]
Sent: Sunday, February 27, 2000 7:51 AM
To: ebXML-Transport@lists.oasis-open.org
Subject: Re: XML Messaging Data Items


The following comments also pertain to John Ibbotson's Initial Draft of 
Message Header Classification for ebXML TP&R Working Group:

In the IETF XML Messaging Requirements, I would suggest that the Message 
Envelop/Manifest (outer wrapper) contain the following information to enable

recipients to have an idea about the contents of messages before opening 
them at the (final) URL to which they are sent:

1. Message subject keyword/s (analogous to intention for sending the 
message);
## This is the purpose of the MessageIntent (see latest draft version 2).
Only one phrase is allowed since it is assumed that a message is sent for a
single specific purpose.##

2. Message duration--in seconds if the message is in a 
video/voice/streaming/mixed-media format for viewing or listening; in word 
count if the message is in text or data for reading (analogous to the word 
count function for MS Word or Powerpoint documents).
##Don't think I like this. Duration only applies to certain types of content
(as you describe) therefore "duration" should be part of the data associated
with that type of content only. I don't think it's TR&P's responsibility to
specify this type of information, although there is no reason why some other
group could not define a suitable XML based structure."

If the message is not encrypted, compressed, or encoded, then the Message 
Header's Action Data should contain this information, for the same reason.
##Disagree for the same reasons as the above.##

Having these items would permit, for example, mobile users to decide in 
advance (say, via receipt of an XML token) whether they want to download a 
particular message (or parts of it) from a series of incoming transmissions.

##Now I think I see where you're coming from. But I still don't think it
should be part of the header. What you really want is a way for a recipient
of a message to know how big it is in advance of opening as they might then
choose not do do so. This is no different from the problem I have acessing
email remotely. I don't want to download a 10MB file over a phone line.
However, the server software I use provides a facility whereby I can specify
rules that can limit the emails downloaded depending on their size, where
they've come from (I don't like junk mail) etc, etc. I think this is a
better place to put this type of functionality rather than overload the
message header with something that will not always be needed.##

  A recipient's knowing, for example, that a particular message is 100 words

long versus 1,000 (or 1 minute versus ten in duration) would be useful, even

if the device or information appliance could download either length.  A 
longer, less important message (screened via XML tokens) might be postponed 
for later downloading to a different device like a PC or laptop.  (Just 
having kilobyte file size might not be so helpful, as it may vary 
considerably depending on the amount and types of included graphics or 
formatting.)

I think the draft under consideration should include this kind of feature.  
However, since I'm new to these various XML standards groups, I'm not sure 
if this is the proper arena to make the suggestion.
##This is a perfectly reasonable place to raise your question.##

By the way, will you be working with the new SyncML group at www.syncml.org 
on the protocols?
##No ... no time ;-) ##

Paul Ulrich
Cambridge, Massachusetts

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com