Subject: [Sipping] [Fwd: Re: Review: draft-ietf-sipping-toip-04.txt: section 6 and subsections]

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 02 Jul 2006 19:01:51 -0700

Tom Taylor wrote:
> Having proposed an organization around system components in my previous 
> note, I will assume that this is what we are aiming for. This means, as 
> one example, that most SIP and SDP-related aspects will be dealt with in 
> the section on signalling capabilities within the communications 
> subsystem description. However, interactions between SIP and other 
> functions will be dealt with in the respective sections -- for example, 
> the relationship between what is presented to the user and the content 
> of the SIP INVITE gets covered under "user interface".
> 
> One overall remark: section 6 is missing a description of the 
> implementation of many of the section 5 requirements. Where I suggest 
> discarding material below because it is covered in section 5, the 
> authors may sometimes want to generate new text dealing with 
> implementation instead.
> 
> Section 6
> =========
> 
> No comment.
> 
> Section 6.1
> ===========
> 
> I'm not sure how much this section should say beyond the first 
> paragraph, in which case it can be moved down as introductory text in 
> section 6.2. The reason is that the content of RFC 3351 and the 
> remainder of section 5.1 are really covered by the more detailed 
> requirements in the rest of section 5.
> 
> The initial paragraph indicating the protocol selections is useful 
> because as indicated above it will be referred to in most of the 
> subsequent sections. May I suggest a slight change in wording:
> 
> "This framework specifies the use of the Session Initiation Protocol
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  (SIP) [3] to set up, control and tear down the connections between ToIP
>                                                                     ^^^^
>  users whilst the real-time text medium is transported ..."
> 
> The reason for the wording change is that I doubt you want to actively 
> prevent someone from specifying an implementation of ToIP using some 
> other signalling protocol by defining it to be SIP-based only.
> 
> The second paragraph beyond the first sentence describes motivation. 
> Since this ground is already covered in 5.1, it can be discarded.
> 
> The third paragraph belongs in the section discussing implementation of 
> signalling within the communications subsystem.
> 
> The fourth paragraph on the virtues of T.140 is more motivation and can 
> also be discarded.
> 
> Section 6.2
> ===========
> 
> No comment.
> 
> Section 6.2.1
> =============
> 
> The use of SIP is presumably an assumption, not a requirement. The 
> paragraph is part of the communications subsystem: signalling 
> capabilities topic.
> 
> Section 6.2.1.1
> ===============
> 
> This section belongs in the communications subsystem: rendezvous 
> capabilities topic. Does this section respond to R17 in section 5?
> 
> Section 6.2.1.2
> ===============
> 
> This looks like a continuation of section 6.2.1.1, and belongs under the 
> same topic. Why was it put into a separate section?
> 
> Section 6.2.1.3
> ===============
> 
> This doesn't seem particularly related to ToIP. Discard.
> 
> Section 6.2.1.4
> ===============
> 
> The first paragraph falls under the communications subsystem: signalling 
> capabilities topic.
> 
> The second para has some content relating to this topic, other content 
> relating to user interface. However, the paragraph is a statement of 
> system requirements rather than implementation options, and belongs in 
> the appropriate parts of section 5. Probably already covered by R5, R23 
> and R28.
> 
> Section 6.2.1.5
> ===============
> 
> This section repeats R23B as I suggested it. Discard.
> 
> 
> Section 6.2.2
> =============
> 
> First para: system requirement -- belongs in section 5, but really looks 
> like a tautology.
> 
> Second, third, and fourth paras: belong under the communications 
> subsystem: media capabilities topic.
> 
> Fifth para belongs under the user interface: presentation topic.
> 
> Sixth para seems to repeat and contradict ("default" vs. "MUST") earlier 
> material -- discard.
> 
> Seventh para: belongs under the communications subsystem: media 
> capabilities topic.
> 
> Eight para: replace "MUST be" by "is" -- this is an example! Belongs 
> under the communications subsystem: signalling capabilities topic.
> 
> Ninth para: belongs under the communications subsystem: media 
> capabilities topic.
> 
> Tenth para: system requirement. Put it into section 5 following or as 
> part of R10.
> 
> Final para: system requirement. Contradicts R11.
> 
> Section 6.2.3
> =============
> 
> First para: belongs under the transcoding topic.
> 
> Second and third paras: covered by definitions. Discard.
> 
> Fourth para: first sentence is a system requirement. It is implied by 
> RFC 3351, but could be added to section 5.2.3. Second sentence is 
> related to the final sentence of 6.2.1.1. Perhaps they should be brought 
> together under the transcoding topic. Remaining sentences belong under 
> the transcoding topic.
> 
> Section 6.2.4
> =============
> 
> No comment.
> 
> Section 6.2.4.1
> ===============
> 
> This entire section presents system requirements and therefore belongs 
> in section 5. Most is covered already. What the authors might want to 
> put under the user interface: alerting and indications topic instead is 
> notes on the indications that should follow specific signalling events, 
> where these aren't obvious.
> 
> Section 6.2.4.2
> ===============
> 
> Content falls under the user interface: alerting and indications topic. 
> The text is not clear to me, but that can wait until the document is 
> reshaped.  (assuming it will be).
> 
> Section 6.2.4.3
> ===============
> 
> System requirements. Move to section 5.2.4. Modify R29 and R30 to be 
> consistent with the content of this section -- they are too specific in 
> their placement of the answering machine function. storage: message 
> taking topic.
> 
> Section 6.2.4.4
> ===============
> 
> First para: first sentence repeats R32 and should refer to that 
> requirement. e.g., "Requirement R32 requires that, in the display of 
> text conversation, users be able to distinguish easily between different 
> speakers. Remainder is an implementation note. user interface: 
> presentation topic.
> 
> Second para: system requirement -- add to section 5.2.4.
> 
> Section 6.2.4.5
> ===============
> 
> Relates to the storage: recording topic. Should refer to requirement R31.
> 
> Section 6.2.5
> =============
> 
> Interworking topic.
> 
> Section 6.2.5.1
> ===============
> 
> Paras 1-5: Implementation notes, I suppose. Interworking: PSTN topic. 
> I'm a little dubious whether the requirement to support SIP and RFC 4103 
> in para 5 is necessary, or is covered by the general specification under 
> communication subsystem.
> 
> Para 6: restates R38. Discard.
> 
> Para 7: system requirement -- doesn't belong here. Use this instead of 
> the existing wording of R35.
> 
> Remaining paras: implementation notes under interworking: PSTN topic.
> 
> Section 6.2.5.2 and subsections: implementation notes under the 
> interworking: cellular topic, I suppose. A bit repetitive from section 
> 5.2.5.2.
> 
> Section 6.2.5.3
> ===============
> 
> OK for interworking: instant messaging topic.
> 
> Section 6.2.5.4
> ===============
> 
> Should probably be merged into 6.2.5. Repeats some of that content.
> 
> Section 6.2.5.5
> ===============
> 
> Is there a motivation for the requirement to support all possible 
> combinations? It doesn't seem to be something that has to be standardized.
> 
> Section 6.2.5.6
> ===============
> 
> No comments.
> 

_______________________________________________
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