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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 18:03:03 -0400

Some comments:

1. You need to expand the acronym SIP in the title of the draft. Seriously.

2. The abstract refers to the document as an Internet Draft. Replace 
that with specification, since its going to be an RFC.

3. I don't think the introduction sufficiently captures the motivation 
for content indirection. It says:

> One limitation of SIP in this regard is in the use
>    of SIP over the UDP transport.  On such a transport, the size of the
>    SIP message is effectively bounded by the MTU to avoid fragmentation.
>    A reasonable nominal value for such an MTU would be 1500 bytes.
>    Taking into account the potential size of routing information, a safe
>    upper bound to use for SIP messages on the UDP transport would be
>    1200 bytes.  Clearly this is not sufficient for carrying any
>    arbitrary payload, though it is perfectly adequate for most session
>    signalling.

this is really moot, since the spec says that you switch to TCP when the 
content exceeds this threshold exactly.

IMHO, the real motivations for content indirection are:

* you don't want to send the content unless you are sure the recipient 
really wants it. indirection allows you to send meta-data, along with a 
refernece to the content, so the recipient can decide if it really wants 
it, and then fetch it. This is crucial in applications such as wireless, 
where bandwidth is at a premium.

* the content may not reside, and may not even be permitted to reside, 
on the senders endpoint (you do point this out)

* Large content in SIP messages might "clog" proxies, potentially 
increasing latency of message traversl through those proxies. That will 
adversely affect other time-senstivite applications of SIP.

4. section 3 says:

> There are several potential immediate users of such a content
>    indirection mechanism. 

"immediate users"? This document will be an RFC that lives forever, so 
"immediate" is not so well defined. I would just say that this section 
provides some example use cases for the mechanism.

5. section 3.1:

> Example information flow for presence notification

Better phrased as "The following is an example message flow for presence 
notification:"

Similar thing with the sentence above the document sharing picture. If 
you mean these to be captions, you need to label them, i.e., "Figure 1: 
Example information flow for document sharing.".

Also, could you please expand the flow to use actual messages? that is, 
separate arows for SUBSCRIBE, 200 to SUBSCRIBE, NOTIFY, 200 to NOTIFY. 
It can be confusing, and anyway, this is recommended by the guidelines 
draft.

6. section 3.2:

> During an instant messaging session, a useful service is document
>    sharing wherein one party sends an IM (MESSAGE request) with an

I suggest you avoid the term "session" here as potentially confusing.

7. section 3.2:

> In this example, a user wishes to exchange a JPEG image that she has
>    stored on her web server with another user she has a IM dialog with.

dialog is another no-no term here.

8. Section 4: I happen to like numbered requirements, so would advise 
that each requirement be phrased as REQ-INDIRECTION-X, for some numeric X.

9. section 4, you write:

>  It MUST be possible to specify the location of content via one or
>       more URIs [3].

what is the meaning of multiple URIs in this context? Do they point to 
identical versions of the content? Do they point to different encodings 
of the same thing?

10. section 4:

> It MUST be possible to specify the purpose and disposition of each
>       URL independently.

First off, use URI, not URL. That applies throughout the document.

Secondly, I think you should explicitly define "purpose" and 
"disposition" here. Disposition clearly means content-disposition. What 
does purpose mean?

11. section 4:

> It MUST be possible to specify the timespan for which a given URL
>       is valid.  Applications of this mechanism MUST specify a lifetime
>       for the URL.  This may or may not be the same as the lifetime for
>       the content itself.

The second sentence is odd. I don't see how its a requirement for the 
content indirection mechanism. Its a potential statement the mechanism 
itself might make.

12. section 4:

> It MUST be possible for the UAC and UAS to negotiate content types
>       when using the content indirection mechanism.

you might want to clarify that you are talking about the type of the 
referenced content, not the "indirection type" itself.

13. section 4:

> The content indirection mechanism MUST be usable as part of a MIME
>       multipart body. [4]

while I agree with this, it appears to be a statement of how the 
protocol has to work, not a requirement of a capability of the protocol. 
I don't think it belongs in here and should be removed.

14. I'd advise adding a security considerations section, which indicates 
some of the security issues with content indirection and points out the 
requirements made to address them.

Rohan Mahy wrote:
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 21:46:56 -0400

Another few points:

There is no requirement listed that the indirection indicate the length 
of the content. I think that this requirement is critical. Its needed 
for features like automatic download when the size is under some threshold.

Similarly, there is no requirement listed that the indirection indicate 
the type of the content. I think thats even more critical than the length.

-Jonathan R.

Jonathan Rosenberg wrote:
>> 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:
>>