Subject: RE: [Simple] RE: draft-lonnfors-simple-binpidf-00.txt

From: [email-masked]
Date: Tue, 15 Apr 2003 11:13:34 +0300

I think the draft should only define a single element that is used to embed external (to the PIDF) content. In fact, I think such an element should look much like an <OBJECT> tag in HTML 4.0.

Having said that, there are three possible cases enabled by such an element:

1) A "direct" http: (or ftp:, etc.) URL to external content
2) A cid: URL to content within the same message body, i.e., a part of a MIME multipart
3) A cid: URL to indirect content within the same message body, i.e., a part of a MIME
   multipart that is of type message/external-body

Cheers,
Aki

 > -----Original Message-----
 > From: ext Adam Roach [mailto:[email-masked]]
 > Sent: 10 April, 2003 20:58
 > To: Khartabil Hisham (NMP/Helsinki); Adam Roach; [email-masked]
 > Subject: RE: [Simple] RE: draft-lonnfors-simple-binpidf-00.txt
 > 
 > 
 > My personal preference is the indirect approach, if for no
 > other reason than the fact that it requires less specification.
 > 
 > /a
 > 
 > > -----Original Message-----
 > > From: [email-masked] 
 > [mailto:[email-masked]]
 > > Sent: Thursday, April 10, 2003 2:44
 > > To: [email-masked]; [email-masked]
 > > Subject: RE: [Simple] RE: draft-lonnfors-simple-binpidf-00.txt
 > > 
 > > 
 > > Actually, we put both solutions in for discussion purposes 
 > > and to get consensus from the list on which is a better 
 > > solution, before we settle for one.
 > > 
 > > We should have mentioned this in the draft, my apologies.
 > > 
 > > Which is your favourite? Direct link reduces the overall 
 > > message size, but indirect link in a cleaner solution.
 > > 
 > > Regards,
 > > Hisham
 > > 
 > > > -----Original Message-----
 > > > From: ext Adam Roach [mailto:[email-masked]]
 > > > Sent: Wednesday, April 09, 2003 9:04 PM
 > > > To: [email-masked]
 > > > Subject: [Simple] RE: draft-lonnfors-simple-binpidf-00.txt
 > > > 
 > > > 
 > > > I have one minor comment on the current binpidf draft.
 > > > 
 > > > It's not clear what the motivation for having both
 > > > direct and indirect links to external content are.
 > > > The rationale for having multiple ways to do it
 > > > should probably be discussed in the document. In
 > > > particular, it would probably be worthwhile to
 > > > explicitly provide an analysis of why the flexibility
 > > > is worth the additional code that implementors
 > > > will need to write to support both modes of operation.
 > > > 
 > > > /a
 > > > _______________________________________________
 > > > Simple mailing list
 > > > [email-masked]
 > > > https://www1.ietf.org/mailman/listinfo/simple
 > > > 
 > > 
 > _______________________________________________
 > Simple mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/simple
 > 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Tue, 15 Apr 2003 13:20:59 -0700 (PDT)

This sounds perfect. An <object> tag with the three
possible URI types that you mention.

/sean

--- [email-masked] wrote:
> I think the draft should only define a single
> element that is used to embed external (to the PIDF)
> content. In fact, I think such an element should
> look much like an <OBJECT> tag in HTML 4.0.
> 

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Apr 2003 01:50:45 -0400

Perhaps I missed something, but I am unsure what problem we are really 
trying to solve here.

In particular, PIDFs arent html; they are meant for consumption by 
automata. Thus, they won't just contain links to content. Any kind of 
content needs to have tags defined which identify its semantics and 
constraints. In that case, the definition of such a tag would state that 
  its content is a URL that points to a web page or a cid URI.

For example, if we want to include thumbnail pictures as part of 
presence, we would need to define a new tag, say <thumbnail>, and the 
specification of such a tag would say that it contains a URI where the 
thumbnail can be downloaded from. So:

<?xml version="1.0" encoding="UTF-8"?>
          <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
              entity="sip:[email-masked]">
           <tuple id="432sd">
              <status>
                <basic>open</basic>
              </status>
              <contact>sip:[email-masked]</contact>
              <note>At home</note>
 
<thumbnail>http://www.example.com/pictures/john.jpg</thumbnail>

            </tuple>
          </presence>

So, I do not see the value in defining a schema for referencing content 
outside of the context of a specific semantic.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Sean Olson" <[email-masked]>
Date: Sat, 19 Apr 2003 12:03:09 -0700

I don't disagree with the need to associate semantics with this content. It
would be nice
however if there were a simple and common way to refer to this binary
content. For example:

              <thumbnail>
                 <object>
                    http://www.example.com/pictures/john.jpg 
                 </object>
              </thumbnail>
            </tuple>
          </presence>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Friday, April 18, 2003 10:51 PM
To: Sean Olson
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Simple] RE: draft-lonnfors-simple-binpidf-00.txt

 

            </tuple>
          </presence>

-Jonathan R.

Sean Olson wrote:
>> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
>> > > > 
>> > > 
>> > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
>> > 
> The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Apr 2003 02:55:59 -0400

What is gained by this, as opposed to just specifying, as part of the 
tag definition for thumbnail, that its contents are a URI for the image?

-Jonathan R.

Sean Olson wrote:
>>>>From: ext Adam Roach
>>>[mailto:[email-masked]]
>>>
>>>>To: Khartabil Hisham (NMP/Helsinki); Adam Roach;
>>>
>>>[email-masked]
>>>
>>>>Subject: RE: [Simple] RE:
>>>
>>>draft-lonnfors-simple-binpidf-00.txt
>>>
>>>>
>>>>My personal preference is the indirect approach,
>>>
>>>if for no
>>>
>>>>other reason than the fact that it requires less
>>>
>>>specification.
>>>
>>>>/a
>>>>
>>>>
>>>>>Subject: RE: [Simple] RE:
>>>
>>>draft-lonnfors-simple-binpidf-00.txt
>>>
>>>>>
>>>>>Actually, we put both solutions in for
>>>
>>>discussion purposes
>>>
>>>>>and to get consensus from the list on which is
>>>
>>>a better
>>>
>>>>>We should have mentioned this in the draft, my
>>>
>>>apologies.
>>>
>>>>>Which is your favourite? Direct link reduces
>>>
>>>the overall
>>>
>>>>>message size, but indirect link in a cleaner
>>>
>>>solution.
>>>
>>>>>Regards,
>>>>>Hisham
>>>>>
>>>>>
>>>>>>From: ext Adam Roach
>>>[mailto:[email-masked]]
>>>
>>>>>>Subject: [Simple] RE:
>>>draft-lonnfors-simple-binpidf-00.txt
>>>
>>>>>>
>>>>>>I have one minor comment on the current
>>>
>>>binpidf draft.
>>>
>>>>>>It's not clear what the motivation for having
>>>
>>>both
>>>
>>>>>>direct and indirect links to external content
>>>
>>>are.
>>>
>>>>>>The rationale for having multiple ways to do
>>>
>>>it
>>>
>>>>>>should probably be discussed in the document.
>>>
>>>In
>>>
>>>>>>particular, it would probably be worthwhile
>>>
>>>to
>>>
>>>>>>explicitly provide an analysis of why the
>>>
>>>flexibility
>>>
>>>>>>is worth the additional code that
>>>
>>>implementors
>>>
>>>>>>will need to write to support both modes of
>>>
>>>operation.
>>>
>>>>>>/a
>>>>>>
>>>