Subject: RE: [Sipping] Fwd: WGLC on draft-ietf-sipping-content-indirect-01.txt

From: "Sean Olson" <[email-masked]>
Date: Fri, 30 Aug 2002 13:56:52 -0700

I think the goal is to allow applications to exchange URLs significant
to the
communication session, but pointing to content that cannot or should not
be transferred through SIP. Large content is one case of this. 

I think Juha's example is one that people have envisioned for a long
time 
for SIMPLE and which most existing IM platforms support.
I send an IM with a URL that I want a user to be able to click through. 
There is an explicit user interaction here. This is different than the
case
where the content indirection is being used to refer to, for example,
the 
SDP for an INVITE. The UserAgent would generally handle this under the
covers.

I believe the same mechanism can be used for both applications. The
distinction can be
called out in the disposition associated with the URL and handled by the
UserAgent appropriately (involving the user as needed).

To address your comment directly, I would like to propose the following
additional requirement:

   It MUST be possible for an application supporting content indirection
to
   process messages containing indirect content identically to messages
   without content indirection aside from the transfer of that indirect
content.

The text is a bit awkward and I would appreciate any alternative wording
people
can come up with.

Thanks!
sean

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Friday, August 30, 2002 1:37 PM
To: 'Rohan Mahy'; [email-masked]'
Cc: Sean Olson
Subject: RE: [Sipping] Fwd: WGLC on
draft-ietf-sipping-content-indirect-01.txt

I have carefully reviewed the draft, and have only one, minor comment.

     "It MUST be possible to process the content indirection without
      human intervention."

I agree with this requirement; however, I wonder if it goes far enough.
For content indirection to be universally useful, I beleive this
requirement should be stronger: it should require that handling of
indirect content MUST be the same as handling of inline content.

This is essentially the answer to the point that Juha made earlier:

  "for example, one can always include an url to a document in the body
of
   the message and let the user to click the url if he/she wants to see
the
   content."

What we're trying to acheive here (and this is made clear in the
document introduction) is the ability to send large message bodies. In
particular, we don't want these large message bodies to be treated in
any way different (from an application perspective) than their smaller
counterparts. I'd prefer this requirement be more explicit.

/a

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Friday, August 23, 2002 15:00
> To: [email-masked]'
> Subject: [Sipping] Fwd: WGLC on 
> draft-ietf-sipping-content-indirect-01.txt
> 
> 
> Hi,  I'm not sure if this got out, as I have not seen it.  In
> any case, 
> I will extend close of WGLC to September 9th so that everyone 
> has fair 
> warning.
> 
> thanks,
> -rohan
> 
> Begin forwarded message:
> 
> > From: Rohan Mahy <[email-masked]>
> > Date: Tue Aug 20, 2002  04:18:07 PM US/Pacific
> > To: [email-masked]' <[email-masked]>
> > Cc: rohan
> > Subject: WGLC on draft-ietf-sipping-content-indirect-01.txt
> >
> > Hi,
> >
> > I'd like to open Working Group last call on
> > draft-ietf-sipping-content-indirect-01.txt.  WGLC will 
> close on Sept 5.
> >
> > thanks,
> > -rohan
> >
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP